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Preface 


This redbook, the result of a residency conducted at the ITSO Austin Center, 
was written to assist those individuals who need to understand the benefits, 
planning, installation, administration, and basic problem determination of 
the Directory and Security Server for OS/2 Warp product. 


We describe many of the benefits that can be reaped with use of the 
Directory and Security Server for OS/2 Warp. These benefits result from the 
integration of OSF/DCE Version 1.1 and the existing OS/2 LAN Server 
architecture. This integration is described in detail to help you understand 
and appreciate the power and scalability of DSS. A description of the core 
DCE components is also included for the DCE novice. 


As products gain features and capabilities, it becomes increasingly 
important to plan the implementation carefully. We discuss planning and 
design issues, so the installation is not only successful but also flexibile 
enough to allow for evolving business needs. Poor planning can result in 
costly reconfiguration and unnecessary downtime. Sample scenarios are 
also included, some of which represent actual customer environments. 


Installation and configuration are covered in detail since they can be 
challenging or frustrating at times. We cover the most common installation 
scenarios and describe the configuration options and our recommendations. 


The DSS administrator now has many new capabilities and functions not 
present in OS/2 LAN Server and OS/2 Warp Server. We describe not only 
the existing functions but also the new, DSS- and DCE-specific options. 
Typical administration tasks, such as address changes and working with 
time zone changes (such as Daylight Savings Time), are also discussed. 


Some customers may have existing DCE cells and now want to integrate 

their OS/2 Warp Server domains into the infrastructure. There are some 

important prerequisites for installing DSS into an existing cell, such as an 
AIX DCE cell. These are discussed to ensure a successful installation. 


Whenever possible, we include real examples of program input and output 
to make concepts easier to understand. 


Some knowledge of OS/2 and OS/2 LAN Server or OS/2 Warp Server is 
assumed. 
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Chapter 1. 


1.1 Today’s 
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Product Overview 


This chapter will help both marketing and technical personnel by describing 
the current OS/2 LAN Server and OS/2 Warp Server environment, including 
the factors that led IBM to develop the Directory and Security Server for 
OS/2 Warp. We continue by discussing the benefits that can be reaped by 
migrating to DSS. After discussing some new concepts, we provide more 
detail on the marriage of DCE and OS/2 LAN Server technology and 
function, including changes to the OS/2 LAN Server access control structure. 


OS/2 LAN Server and OS/2 Warp Server Environment 


OS/2 LAN Server Version 4 and OS/2 Warp Server provide an excellent 
foundation for Client/Server networking and application serving, as well as 
file and print sharing in a local area network (LAN) and wide area network 
(WAN) environment. Over the past several years, many companies of all 
sizes have implemented these platforms within their environments. In 
particular, larger corporations have adopted the LAN Server standard. In 
many companies, OS/2 LAN Server is one component of a multiple-tier 
information systems infrastructure, consisting of workstations (DOS, 
Windows, OS/2), LAN Servers (OS/2 Warp Server and LAN Server, Windows 
NT, Novell Netware), mid-range hosts (such as AS/400, Unisys) and large 
systems (such as MVS, VM). 


As companies grow into larger corporations, and/or the use and reliance on 
information systems within companies expands, then the problems relating 
to implementing and managing information systems also grow in size. The 
single location becomes multiple locations within a city, and satellite offices 
are established in other cities or even countries. This evolution from a 
centralized to a distributed environment introduces new problems. For 
example, backup/restore and problem management procedures that worked 
well in a centralized environment now work poorly or not at all ina 
distributed environment. Employees who need to access distributed 
resources may need to keep track of multiple resource names, and they 
may have a user ID for each of these distributed systems. 


IBM examined the architecture of OS/2 Warp Server and OS/2 LAN Server 
Version 4 and realized that some changes would need to be made in order 
to meet company growth and changes in the information systems 
infrastructure. Early on, IBM realized the following: 


¢ Protocols designed for local area networking (such as NetBIOS/NetBEUI) 
do not necessarily scale well in wide area networks. 


¢ Very large customers need greater scalability. 


* Interoperability and coexistence with other protocols and platforms is a 
necessity. 


* Customers need to maintain effective systems management even as 
environments get very large. 


« As new solutions are developed, customers still want backward 
compatibility with existing hardware and software. 


IBM looked at its own software technology and also at other standards in 
the marketplace. IBM chose to integrate the Open Group’s Distributed 
Computing Environment (DCE) architecture with OS/2 LAN Server and OS/2 
Warp Server. 


The Open Group (which is a merger of two earlier groups, X/Open and the 
Open Software Foundation or OSF) is a collaboration of many hardware 
vendors, software vendors, customers, and consulting firms. The OSF 
began in 1988 with the purpose of supporting the research, development and 
delivery of vendor-neutral technology and industry standards. One such 
standard developed was the Distributed Computing Environment (DCE), 
which is the name for a set of integrated services designed to support the 
development and use of distributed applications in a multiplatform, 
multivendor environment. DCE has many features, some of which are: 


- A set of open standards, not controlled by any one vendor 

« Works on many vendor systems and operating system platforms 
* Offers virtually unlimited scalability 

* Designed to work well in a wide area networking environment 

- Uses industry-standard protocols 


These features are the reasons IBM chose to integrate OS/2 LAN Server 
and OS/2 Warp Server with DCE. 


1.2 Introducing the Directory and Security Server for OS/2 Warp 
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In July 1996, IBM announced an extension to the OS/2 LAN Server and OS/2 
Warp Server environment called the Directory and Security Server for OS/2 
Warp (DSS). DSS delivers two major components: 


1. An implementation of Open Software Foundation DCE Version 1.1 on the 
OS/2 Warp, Version 3 platform. This provides the standard DCE 
services, such as Directory, Security and Time, and does not require 
OS/2 LAN Server or OS/2 Warp Server as a prerequisite. 


2. A set of features that can be added to existing OS/2 LAN Server Version 
4 or OS/2 Warp Server machines and that allow multiple domains to: 
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* Take advantage of the security and communication services 
provided by DCE 


« Share file, print and serial resources across a whole enterprise 


* Be merged into a single, scalable administrative unit called a cell 


To fully appreciate the enhancements made to OS/2 Warp Server when it is 
migrated to the Directory and Security Server for OS/2 Warp, you should be 
familiar with the basic functions of DCE. We recommend you read through 
Appendix A, “Introduction to DCE” on page 173 where the basic functions of 
DCE are described. 


1.3 DSS Benefits 


This section describes several areas where DSS enhances the existing OS/2 
LAN Server and OS/2 Warp Server environments. It is not intended to be a 
complete list of all benefits, but it gives you an idea of the improvements 
that can be realized by using the Directory and Security Server for OS/2 
Warp. 


1.3.1 Enterprise Directory 
Today’s LAN environment may consist of many servers or domains, of 
users, groups and resources scattered throughout a company. In some 
cases, a user may have a user ID and associated password on many 
different servers. As the number of servers increases, administrators and 
users spend unnecessary time keeping track of where a particular resource 
resides. Also, when a user has many IDs in multiple locations, there is a 
danger that he will be forced to write down passwords in order to remember 
them, (which obviously represents a potential security exposure), or he will 
try to use the same password for all his user IDs. This will mean having to 
synchronize all the passwords whenever any one changes, which is very 
unproductive. (Research has shown that a user maintaining ten passwords 
which need to be changed every 30 days spends around 3 hours per year on 
this task, which represents a significant cost to a large company with a 
large number of users. This does not include time spent by help desk staff 
when they are called for assistance). 


The Directory and Security Server for OS/2 Warp provides important benefits 
to both administrators and users. The resources of all servers are 
consolidated into a single database called the Cell Directory, or Namespace. 
User IDs and groups from many domains are also consolidated into a single 
database, called the Cell Registry. An administrator from a single 
workstation is able to manage resources and users across the whole 
enterprise. A user needs only one user ID and password to access any 
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resource in the enterprise. Users no longer need to waste time keeping 
track of multiple user IDs and synchronizing passwords. 


1.3.2 Enterprise Security 


OS/2 LAN Server and OS/2 Warp Server already provide a secure network 
operating system environment through password enforcement, access 
control checking and local security (for servers with the 386HPFS File 
System). However, as a company grows to include heterogeneous systems, 
wide area network connectivity and Internet accessibility, security becomes 
even more important. 


DSS builds upon OS/2 LAN Server’s security model to extend it from the 
workgroup to the distributed enterprise-wide networking environment. DSS 
addresses connectivity, interoperability and security issues by implementing 
the OSF/DCE Version 1.1 security mechanisms, such as Kerberos, which 
implements third-party authentication. This ensures that all parties in the 
network successfully authenticate themselves to a trusted third party before 
trying to access resources or provide services for clients. This minimizes 
the chance that access to information will be given to an unauthorized 
system or user. 


Note: DCE supports encryption to Data Encryption Services (DES - North 
America) or Commercial Data Masking Facility (CDMF -outside North 
America) standards. APIs are supplied which allow a user-written DCE RPC 
application to encrypt all data that crosses the network. DSS Servers use 
encryption when communicating with each other, but application or file data 
being passed from a DSS Server to a DSS Client or legacy client is not 
encrypted unless specifically implemented by an application. 


1.3.3 Scalability 


4 


OS/2 LAN Server and OS/2 Warp Server keep the user account information 
in a proprietary database within a file called NET.ACC. Other information 
regarding the users and other resources in the OS/2 LAN Server domain 
resides within a subdirectory structure called the Domain Control Database, 
or DCDB. Both the NET.ACC file and the DCDB reside on the Primary 
Domain Controller. Since the NET.ACC file is replicated to each member 
server in the domain, problems can arise when the number of users grows 
into the thousands and the number of servers also increases. A domain is 
limited to 128 defined servers. In addition, there is a limit of 16,000 defined 
users, groups and servers in a domain, and there is a limit of 256 total 
defined groups. Although 16,000 seems like a large number of users, there 
are other limitations that make the practical limit lower. 


The Directory and Security Server for OS/2 Warp’s key feature is the 
implementation of the OSF DCE V1.1 architecture. The benefit is that it 
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allows OS/2 LAN Server and OS/2 Warp Server to scale much beyond 16,000 
users and 256 groups within a domain. In fact, DSS does not have an 
architectural limit on the number of defined users and groups. This is 
limited mainly by the capacity of the hardware and software platform which 
implements these DCE functions. 


The Directory and Security Server for OS/2 Warp also achieves hardware 
and platform independence. While DSS operates on Intel-based systems, 
DSS can interoperate with DCE servers on any operating platform (for 
example, AIX, HP-UX, DEC-Ultrix, OS/390). This allows the most appropriate 
platform to provide the DCE services in greatest demand. The benefit is that 
this allows for an almost unlimited growth in capacity and scalability. Today, 
there are DCE-enabled customers with over 75,000 users in their 
heterogeneous environments. 


1.3.4 Ease-of-Use 
OS/2 LAN Server Version 4 brought unprecedented ease-of-use to LAN 
administrators through the implementation of an intuitive graphical user 
interface (GUI) for administration. Assigning a resource to a group of 100 
users is as simple as using the mouse to drag and drop the resource icon to 
the group icon. Many other administrative tasks were simplified through the 
GUI administration. 


The Directory and Security Server for OS/2 Warp enhances the GUI 
administrator interface and enables DSS-specific actions to be performed 
within the GUI. In addition, the DSS GUI also includes a subset for DCE 
administration. The benefit is that the LAN administrator can administer any 
DCE platform (OS/2, AIX, HP-UX, MVS, DEC Ultrix, and so on) from the one 
graphical interface, the DSS GUI, on an Intel workstation. The administrator 
is still able to manage any OS/2 LAN Server domains that have not been 
migrated to DSS from the same GUI interface. 


Administrators who prefer a command-based environment will be happy to 
know that the command line interface continues to be available for 
administration, which is particularly beneficial for automating repetitive 
tasks through scripts. 


1.3.5 Better Administration 
Customers with large or distributed OS/2 Warp Server environments often 
need administrative support wherever the servers are physically located, 
whether in a headquarters with several thousand employees, branch office, 
claims office or police precinct with only a handful of employees. Some 
companies have their own unique administrative staff for each LAN Server 
domain. Most of these staff members have full administrator authority. This 
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means that they automatically have access rights to all data on the servers 
and they have the ability to add and delete other administrators at will. 


The Directory and Security Server for OS/2 Warp allows the flexibility to 
consolidate administrative function to a central or regional location because 
of the implementation of a single enterprise directory, where all resources 
now logically reside. Since all domains are part of one cell, companies can 
now create several levels of administrative capability, including a cell-wide 
administrator, and a domain-level administrator. This allows a person to 
administer a workgroup, but does not have authority outside their particular 
area and without having read access rights to all the file resources within 
their area. Also, they cannot create administrators with greater authority 
than they have. 


As a result of the improved access control, DSS allows auditing functions to 
be managed by a user other than the administrator. This means that all 
critical operations can now be independently monitored and there is no 
chance for a disgruntled administrator to make harmful changes and then 
hide his actions by manipulating an audit log. Not only is administration 
easier in DSS, but it is also more easily controlled. 


1.3.6 Protocol Support 
The default NetBIOS protocol used by OS/2 LAN Server and OS/2 Warp 
Server provides extremely fast client/server communications. While this is 
excellent for a LAN environment, it does not suit the WAN environment very 
well because of its use of broadcasts and the fact that it is not a routeable 
protocol. IBM enhanced OS/2 LAN Server and OS/2 Warp Server to include 
support for RFC 1001/1002 NetBIOS, which is an open-standard design for 
allowing NetBIOS APl-based applications (such as LAN/Warp Server, 
Microsoft Windows NT, Artisoft LANtastic, and others) to communicate over 
a TCP/IP network. This support is also included in DSS. In addition, the 
DCE components of the client and server can communicate over native 
TCP/IP, which benefits companies who increasingly use TCP/IP as their 
WAN protocol of choice. Also, as OS/2 LAN Server was designed for use in 
the LAN environment, server to server communications can sometimes 
cause high utilization when crossing WAN links. The DCE inter-server 
communications used in DSS, however, is designed for use in the WAN 
environment and makes more efficient use of low-bandwidth links. 


1.3.7 Compatibility with Current Environment 
Whenever new technology is introduced, most customers cannot ignore their 
existing infrastructure and just move to the latest hardware and software. 
One of IBM’s most important design points was to make sure that today’s 
OS/2 LAN Server or OS/2 Warp Server customer can still utilize their 
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existing hardware and software platforms. Existing LAN clients who can 
communicate with OS/2 LAN Server and OS/2 Warp Server can continue to 
access DSS resources as they are today. Also, new clients based on DSS 
can interoperate with existing servers. 


Maintaining compatibility with existing environments was also important 
when designing migration paths. DSS allows the customer to upgrade 
servers and clients as their schedule allows, which means that an OS/2 
Warp Server Domain Controller can be upgraded to DSS, but the additional 
servers are not required to be upgraded. The benefit is that the customer 
can upgrade based on their requirements and time frames, not the software 
requirements. 





1.4 New Concepts 


1.4.1 Cells 


Although DSS extends the existing OS/2 LAN Server architecture, there are 
some new constructs and definitions to describe. They are cells and 
resource domains. 


The key DSS concept is the cell. The cell defines the basic unit of 
administration within DSS. Although it can be compared to an OS/2 LAN 
Server domain, the DSS cell is much larger in scope and capacity than an 
OS/2 LAN Server domain. While an OS/2 LAN Server domain is usually 
used to define all of the resources for a single workgroup, a cell can define 
all of the resources and accounts for a business line, a region, or an entire 
company. For example, in a situation where a company has several branch 
offices, each of which was an OS/2 LAN Server domain with its own 
administrator, it is now possible to migrate each of those domains into a 
single DSS cell. 


All user and group information for a cell is stored in the cell registry. That 
means that accounts have only one password to change and administrators 
have only one definition to maintain for each account. 


1.4.2 Resource Domains 


For added administrative flexibility, the DSS cell can be divided into several 
smaller administrative units that can have a hierarchical relationship. 
These smaller administrative units are called resource domains. When 
existing OS/2 LAN Server or OS/2 Warp Server installations are migrated 
into cells, each existing domain becomes a resource domain in the cell. 
The administrator of the OS/2 LAN Server domain can continue to 
administer the resources that were part of that domain by becoming an 
administrator of the resource domain to which the OS/2 LAN Server domain 
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was migrated. Because resource domains have a hierarchical relationship, 
new, more powerful and more flexible administrative structures are now 
possible. For more information about resource domains, refer to 2.2.2.1, 
“Example Resource Domain Relationships” on page 34. 


Although users are defined to the cell, they are associated with one or more 
resource domains. However, a user with one user ID and password is able 
to access any resource in any resource domain within the cell. Aliases 
continue to exist in, and are unique to, the resource domain. 


1.5 How Does DSS Integrate OS/2 LAN Server and DCE? 


To understand what happens when an OS/2 LAN Server or OS/2 Warp 
Server domain is migrated to the DSS environment, let us first review how 
security and directory are managed by the LAN Server domain. Those with 
a strong OS/2 LAN Server background will be familiar with most of these 
concepts. Then, we will discuss the changes that occur to the LAN Server 
structures and where the domain information goes. 


1.5.1 Review of LAN Server Architecture 
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OS/2 LAN Server is built upon the domain concept to provide a single 
system image for user logon and resource access. Generally, an OS/2 LAN 
Server network may consist of one or more domains, depending on the size 
and number of workgroups that exist in an organization. These domains are 
independent of each other and are administered separately. 


The key element of OS/2 LAN Server’s security subsystem is the User 
Account Subsystem (UAS), a database of user and group definitions for a 
single domain, contained in the NET.ACC file. This file is present on every 
server in the domain. The master NET.ACC file is at the Domain Controller 
and this file is synchronized between the servers in the domain by the 
NETLOGON service. The UAS also contains other user information such as 
the allowed logon hours and the home directory location. 


1.5.1.1 User and Group Accounts File (NET.ACC) 

For migration and interoperability purposes, the internal format of NET.ACC 
will be described. This will help in understanding the structure and use of 
the NET.ACC as OS/2 LAN Server’s security database and also assist in 
planning for the migration of an OS/2 LAN Server environment to DSS. The 
NET.ACC file is broken into three main sections: 


Header Information Also referred to as the modals containing global 
settings most of which can be viewed with the NET 
ACCOUNTS command. Parameters listed in this 
section include the integrity information, update 
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counter on DC and Additional Server (for NET.ACC 
synchronization), minimum password length, 
computer name and server role. 


User/Group Definitions List of Group names, User IDs and names, 
encrypted passwords, group membership, home 
directory definitions, and statistics counters. 


Access Control Profiles For non-HPFS386 file system resources such as 
serial devices, printers, named pipes and FAT 
drives. This section consists of resource name, list 
of users and their access rights (Read, Write, 
Create, Delete, Execute, Attribute and 
Permissions). This information is server-specific 
and as such it is not replicated to other servers in 
the domain. Servers with HPFS386 installed store 
their access control profiles as an integral part of 
their file system. 


One of the main functions of the NETLOGON service in OS/2 LAN Server is 
as an announcer, notifying additional servers of NET.ACC changes to enable 
them to submit update requests to the domain controller. To protect against 
unauthenticated intruders, all member servers in the domain belong to a 
group called SERVERS with each server having a unique ID and an 
associated password defined. This internal password is exchanged in 
authenticating sessions between member servers and their domain 
controller to guard against intruders. 


The NET.ACC synchronization process is essential to the integrity of OS/2 
LAN Server’s security subsystem as NET.ACC is used for the session 
authentication at the initial user logon and subsequent authorization when 
accessing network resources. However, as NET.ACC is specific to a 
domain, cross-domain operations require additional administration to enable 
a user access to resources outside of their logon domain. To have access 
controls at the user or group level (as opposed to the GUEST ID), you must 
define the user in each external domain where resource access is required. 


1.5.1.2 Domain Control Database (DCDB) 

Another important database in the OS/2 LAN Server architecture is the 
Domain Control Database, or DCDB. The DCDB contains additional 
information about the domain, such as user logon assignments, Public 
Application definitions, and the domain’s alias definitions. This information 
for the entire domain allows OS/2 LAN Server to maintain its single system 
image. 
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Aliases in the Domain Control Database perform a simple directory function 
in the LAN Server domain. A user can access a file or printer resource in 
the domain by using the alias name without needing to know the name of 
the server on which the resource resides. With aliases, the location of a 
resource can be moved to another server without having to make any 
changes at the client. 


1.5.1.3 Logon Process 

When a user logs on at an OS/2 or DOS LAN requester (in the context of 
DSS, we will call these clients /egacy clients), a broadcast is first sent to 
locate a Domain Controller (or Backup Domain Controller). Once a server 
has responded, the user sends the password to this server, which validates 
the user against the contents of NET.ACC. On successful validation, the 
server will look up and resolve the user’s logon aliases. The requester will 
then connect to the additional servers which hold his logon assignments. If 
the user needs to access a resource in another OS/2 LAN Server domain, 
then the user ID and password must be in the NET.ACC file for that domain. 
This means they must be defined as a user in that domain and they must 
make sure that the passwords are always synchronized between domains. 
See Figure 1 on page 11 for the diagram which accompanies the more 
detailed description that follows. 
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Figure 1. Logon Flow between Client and Domain Controller 


1. 


After the Session_initialized frame and the Session_Confirm commands 
are complete at the NETBIOS layer, the requester sends the Negotiate 
SMB command . In this frame, the requests tells the server the SMB 
dialects that it can accept. Although, there are several dialects listed, 
there are two main categories: User-level security with password 
encryption (which requires a valid user ID/password combination), and 
share-level security. 


The domain controller or backup domain controller handling the logon 
will respond to the requester by selecting the SMB dialect which offers 
the highest security mode, for example, LANMAN2.1. The domain 
controller also sends the client a randomly generated encryption key. 


The LAN requester logon program uses an encryption algorithm to 
encrypt the password entered by the user in the logon panel or the 
command line. The resulting encrypted password should match the one 
stored in NET.ACC on the domain controller. 


The LAN Requester logon program then encrypts the already encrypted 
user password with the random encryption key supplied by the domain 


Chapter 1. Product Overview 11 


12 


controller. This doubly encrypted password is called a proof. The LAN 
Requester logon program then sends the proof to the domain controller. 


5. The LAN Server domain controller retrieves the encrypted user 
password stored in NET.ACC and encrypts it with the same random key 
it sent to the requester. Then this doubly encrypted password is 
compared to the proof received from the requester. If they match, the 
user is authenticated. 


6. Since the domain controller has authenticated the user, it sends a 
response to the requester indicating that session setup is complete. 


Following the session setup, the DCDB information is processed and the 
user receives the logon environment (logon assignments, Public 
applications, and so forth). Once users are given the working LAN 
environment, they are ready to access servers in the domain. 


Note: Setting up subsequent authenticated sessions with resource servers 
is similar to the initial domain logon. The requester will negotiate the SMB 
protocol to use with each additional server it needs to connect to. In turn, 
additional servers supply the requester with a random number used to 
compute the doubly encrypted password (proof). Once the proof is verified 
as valid, the session setup completes and the network request (such as NET 
USE) is handled. 


1.5.1.4 OS/2 LAN Server Access Control Model and Authorization 

To understand the difference between DSS’s authorization mechanism and 
that of OS/2 LAN Server, the basics of the access control list (ACL) structure 
should be discussed. 


OS/2 LAN Server supports what is called a sparse ACL model, which means 
that access controls are not necessarily defined for each object. Instead, 
ACLs exist only on physical resources and not on object definitions. An 
example of an object is a Public application definition, a user or group 
account, whereas a physical resource could be a printer or a file directory. 
Authorization in cases where ACLs do not exist is assumed or determined 
by an account’s administrative authority or operator rights. For example, by 
default, an administrator will have total control over the domain, which 
means they can create, delete and modify all account and group definitions, 
and resource and application definitions. They can also delete auditing logs. 
However, an account with print operator privileges can create, delete and 
change only print resource definitions. 


This model is not limited to object definitions, it also extends to the physical 
resources defined in a domain. This effectively means that an account with 
administrator privileges will automatically have total rights over all domain 
resources regardless of whether they are defined in the Access Control List 
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for the resource alias or not. In LAN Server, there are three basic account 
types that can be defined: Administrator, User and Guest. In addition, an 
account with type of User can be granted special operator privileges. 


Administrator There are no limits imposed on this account regarding 
all aspects of domain administration relating to 
user/group and resource definitions. This user type is 
not subject to access control restrictions. 


User By default, this type of account has no administrative 
authority in the domain. However, there are four 
operator privileges that can be granted to a “user” 
account to allow: 


- Print Queue Management (PRT_OP) 

¢ Group and User Account Management (ACCT_OP) 
* Serial device Resource Management (COMM_OP) 
* Server Resource Management (SRV_OP) 


Guest This type only has access to resources within the 
domain that has the GUEST user ID or GUESTS group 
ID in the access controls for that resource. A guest 
account can be created from the command line by 
typing NET USER userid password /ADD /PRIV:GUEST 


For physical resources that exist in a domain, there is an alias definition and 
an associated Access Control Profile (ACP) which comprises a list of entries 
containing a user ID or group ID and the permission. The ACP is used to 
either restrict or grant access to accounts requesting to use a specific 
resource. The LAN Server authorization mechanism proceeds in the 
following order: 


1. An access control profile is first sought for the resource the user is 
trying to access (such as a file). If found, the ACL is read and the user 
name or associated group names is searched. If the user or associated 
group is listed and has sufficient permissions, then the request is 
allowed. 


2. If no such profile is found, LAN Server will check for an access control 
profile for the object’s parent. For a file, this is the directory which 
contains the file. For a directory, this is the root of the drive (for 
instance, C:, not C:\). Again, if found, the ACL is read and the user 
name or associated group names is searched for. If found with 
sufficient permissions, the request is allowed. 
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1.5.2 Migrating a Domain Controller to DSS 
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Now that we have reviewed the existing OS/2 LAN Server and OS/2 Warp 
Server architecture, let’s discuss what happens when DSS is installed. 


When an OS/2 LAN Server or OS/2 Warp Server Domain Controller is 
migrated to DSS, the user, group and resource information move into 
databases controlled by DCE-enabled servers. During this process, several 
things happen. 


A new Resource Domain appears in the Cell Directory Service (CDS) 
namespace. The control information in the NET.ACC file and the DCDB is 
migrated to the DSS Master Security Server and to the DSS Initial Directory 
Server. The old OS/2 LAN Server user IDs and groups are created as DSS 
user IDs and groups in the registry. Other user information from the 
NET.ACC file such as home directory location, and the user’s encrypted 
OS/2 LAN Server password are also stored in extended registry attributes 
(ERAs) on the DSS Security Server (for more information on extended 
registry attributes, please see page 188). Aliases from the DCDB now 
appear as aliases in the Resource Domain in the CDS. Logon information 
from the DCDB, however, is moved to ERA’s in the registry. 


If only the Domain Controller is migrated to DSS, then any legacy Additional 
Servers or Backup Domain Controllers still need to be able to synchronize 
their NET.ACC files with the Domain Controller (the Backup Domain 
Controller also needs to synchronize the DCDB). To support this, the 
migration of the Domain Controller installs some components which 
together are known as the LAN Server Integration (LSI) code. These 
components include RGYSYNC and DIRSYNC. 


RGYSYNC Synchronizes user IDs and groups between the registry and 
NET.ACC on the Domain Controller, synchronizes home directory 
location, password and other user-specific information between 
extended registry attributes and NET.ACC 


DIRSYNC Synchronizes alias information between the nearest cell directory 
replica and the DCDB on the Domain Controller, synchronizes 
logon assignments between extended registry attributes on the 
nearest security replica and the DCDB 


Additional servers and Backup Domain Controllers in the domain which 
have not been migrated to DSS are still synchronized with NET.ACC and the 
DCDB on the domain controller via the NETLOGON and the DCDBREPL 
services. No configuration changes are necessary on the legacy servers. 


The RGYSYNC service does not cascade all user IDs and groups from the 
registry (this could be many thousands) to the NET.ACC file - only those 


Inside DSS for OS/2 Warp 


users and groups who have been associated with the resource domain. 
Therefore, the list of users and groups in the NET.ACC file is a subset of the 
total user population of the cell. When a domain is migrated to DSS, all 
existing users will be automatically associated with the new resource 
domain. However, if you wish a user to be able to access resources on 
legacy servers in other resource domains, then he will have to be 
associated to that domain (by an administrator). 


Notes: 


1. In general, when migrating a Domain Controller, if you require the 
RGYSYNC and DIRSYNC services, also install a security replica for 
those services to function effectively. 


2. Once a domain has been migrated to DSS, most OS/2 LAN Server 
commands that made changes to the NET.ACC file or the DCDB are now 
automatically redirected to the registry or cell directory on DSS servers. 
These changes are synchronized back to NET.ACC and the DCDB. There 
may be some restrictions or changes when using the command line for 
administration. For limitations in resource domains, see 2.2.1, “Planning 
Migration to DSS” on page 29. 


3. Every DSS cell requires one Password Synchronization service, which 
should reside on a DSS server. One of the functions of this service is to 
synchronize the passwords in the DSS registry with the encrypted LAN 
server passwords stored in the extended registry attributes. The 
Password Synchronization server is installed by default with the DSS 
Master Security replica. For more information on password 
synchronization, refer to 6.2, “Password Management Considerations” 
on page 168. 


4. If you are migrating into an existing DCE cell, there are some important 
considerations. Please read Chapter 6, “Using DSS in Heterogeneous 
Environments” on page 167 for additional information. 
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Figure 2. Cell Registry Tree. HODOM Domain Controller Migrated to DSS. 


In Figure 2, an OS/2 Warp Server Domain called HODOM is migrated to 
DSS. The domain is now called a resource domain, and it appears under 
the realms subdirectory tree structure. The users (USER1 through USERn) 
are listed under the accounts directory. This is the level where users are 
defined. Although there is a USERS directory under the HODOM resource 
domain, this USERS directory indicates which users from the accounts 
directory are associated to the HODOM domain, so they may access 
resources in the HODOM resource domain. Two groups, MYGROUP1 and 
MYGROUP2, are under the groups directory. 
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Figure 3. Directory Namespace Tree. HODOM Domain Resources Migrated to DSS. 


Figure 3 represents a portion of the CDS namespace. The OS/2 Warp 
Server Domain Controller, LSDC1, for domain HODOM, was migrated to 
DSS. The server name appears in the DCE hosts directory and also in the 
HODOM directory under subsys\realms, because it is a server in that 
resource domain. The HODOM resource domain also appears under 
resources\realms. Two OS/2 Warp Server aliases, OS/2 Freelance (FLG) 
and a DOS editor (MARKUP) are shown as objects under HODOM. Aliases 
now exist in the resource domain after migration. So, for a user to access 
one of these aliases, they must be associated to the HODOM resource 
domain (under the HODOM\USERS directory in Figure 2 on page 16) and 
given proper access control permissions. 


1.5.3 Legacy Client Logon after Domain Migration to DSS 

A legacy client (DLS, Win95, Windows NT or OS/2 LAN Requester) can log 
on to the migrated Resource Domain without any configuration changes. At 
logon time the user fills in his logon panel with user ID, password and 
Domain name—although the Domain name now represents a resource 
domain. As before, the requester broadcasts to locate a Domain Controller, 
and now the DSS Domain Controller responds. Again, the client sends his 
encrypted password to the server. At this point the Domain Controller 
authenticates with the security server on behalf of the client (using a secure, 
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third-party authentication mechanism based on Kerberos protocols - see 
A.5.1, “Authentication Service” on page 180 for full details). 


On successful validation the server will obtain from the registry privilege 
information for the user (group membership and so on) which it will store in 
a PAC (Privilege Attribute Certificate) retained at the server, and used 
whenever the client tries to access resources on that server. The client will 
access the DCDB to obtain logon assignments and home directory location. 
The requester, as before, stores its encrypted password in memory, then 
attempts to make connections to the servers specified by his logon 
assignments. If these servers are legacy servers, then validation will be 
made against the NET.ACC file, as before. If the servers are in other 
resource domains, then note that the user ID and password in the NET.ACC 
of each server will have originated from the same entry in the registry—the 
user only needs to maintain a single user ID and password. If the logon 
assignment points to a server which has been migrated to DSS, then when 
the connection attempt is made, this DSS server will again contact a 
security replica to validate the user and to obtain group membership and 
attribute information for this user. 


If the client has been migrated to DSS, then at logon time the user is 
presented with a logon panel where he enters, not a Resource Domain 
name, but the name of the cell. The logon request is processed directly by a 
DSS security server (which may, or may not be situated on the DSS Domain 
Controller). The logon authentication process uses the Kerberos, third-party 
authentication mechanisms, and on successful authentication, the client 
receives his logon assignments and credentials, which can be used to 
directly establish sessions with DSS servers. If the DSS client needs to 
establish a session with a legacy server, then it does this by establishing a 
session and eventually passing a doubly-encrypted password to the legacy 
server, as if it were a legacy client. 


1.5.4 Legacy Backup Domain Controllers 
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It is possible that there will be one or more legacy Backup Domain 
Controllers in a resource domain and that when a legacy client attempts to 
log on, one of the first to respond is the Domain Controller In this case, the 
logon is a purely OS/2 LAN Server process and takes place exactly as if the 
domain had not been migrated to DSS. Once the client has been validated, 
if it attempts a connection to a DSS server, then the DSS server will contact 
a Security server in order to extract the user’s ERA information in order to 
authenticate the client and obtain its credentials. Note that having legacy 
Backup Domain Controllers in a Resource Domain is a valid way of sharing 
logon load and thus improving logon performance for legacy clients. 
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1.6 DSS Access Controls 


The previous sections described what happens to Domain Controllers after 
DSS is installed and the impact on legacy clients and Backup Domain 
Controllers. This section discusses the new DCE-based Access Control 
architecture implemented by DSS. There are some significant changes 
compared to OS/2 LAN Server and OS/2 Warp Server. 


Section A.5, “DCE Security Service” on page 179 discusses the components 
of the DCE Security Service. The Access Control List facility is one of these 
components. This facility, in combination with the Privilege Service, gives 
administrators and resource owners greater control over what operations 
can be performed by which user. DSS servers implement a DCE-based 
access control model different from the authorization architecture utilized by 
LAN server. In DSS, access is controlled for Registry objects, entries in the 
CDS Directory and resources in the File and Print Server. The key features 
of access control under DSS are: 


¢ Access Control Lists (ACLs) exist on every object maintained in the DSS 
namespace. 


« Access to resources is always determined by ACLs and not derived 
from the account’s privilege level or operator rights. 


¢ Foreign users and groups belonging to a different cell can be specified 
in the ACLs. 


The authorization model implemented in DSS is based on the DCE 
architecture where access to all resources is determined by ACLs. This 
approach is in contrast to LAN Server especially in the account 
administration and resource definition aspects of the domain where access 
is often determined by an accounts authority or operator rights. The access 
control mechanism implemented in DSS is not limited to the physical 
resource definitions (such as subdirectories); it extends to object definitions 
such as group and application definitions. This approach is based upon 
making a distinction between setting access control on a physical entity 
(subdirectory) and controlling permissions to the object or alias definition 
pointing to the same resource. 


The DSS resource domain concept forms the basis for integrating Legacy 
domain-based resources (file and print aliases, public applications and 
servers) into the DCE cell directory namespace. DSS also provides the 
mechanism for controlling access to these resources by predefining special 
resource domain groups to represent the various privilege levels supported 
in LAN Server. By default, these groups are added to the ACLs of resources 
that exist on DSS servers such that the authority granted to users belonging 
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to these groups is equivalent to that granted to administrators and operators 
in LAN Server. The default access control lists assign the following 
permissions to these groups: 


ADMINS This account can administer all aspects of the resource domain. 
For example, administrators can delete and change the settings 
of the resource domain. They also can create, delete, and 
change resource, server, and public application definitions in the 
resource domain. Note that they cannot add or delete users, 
since users are not defined in a resource domain. They are 
associated to the resource domain from the cell user definitions. 


SRV_OP_ The Server operator account can administer directory, printer, 
and serial device resource definitions, server definitions, and 
Public applications in the resource domain (such as resources on 
legacy servers). 


PRT_OP_ The Print operator account can administer printer resource 
definitions in the resource domain. 


COMM_OP This account can administer serial device resource definitions in 
the resource domain. 


USERS These accounts, by default, have no administrative authority in 
the resource domain, but have access (subject to permissions 
granted) to resources defined to the resource domain. 


Note: The accounts operator privilege is no longer supported in DSS. In 
OS/2 LAN Server, this user type can add, delete and modify user and group 
definitions (but not users with ADMIN authority). In DSS, only members of 
the group acct-admins can make changes to information in the registry. 


1.6.1 Authorization 
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When a DSS client requests access to a resource on a DSS Server, the 
server must determine whether the client has permission to access the 
resource in the way the user wants to access the resource. For example, if 
the DSS client wants to write to a file, the DSS Server must determine if the 
client has permission to write to the file. 


DSS uses the DCE authorization model to determine whether users have 
permission to access resources. Using this model, DSS: 


1. Checks the Extended Privilege Attribute Certificate (EPAC) of the DSS 
client to determine the ID of the user and the IDs of any groups of which 
the client is a member. (The client passes the EPAC to the server when 
the client establishes a secure session with the server, as described in 
A.5.2, “Mutually Authenticated Sessions” on page 184.) 
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2. Checks the access control list of the resource the client wants to access 
to determine whether the client has the proper permission to access the 
resource. 


Note that this process does not check the user type (such as cell 
administrator, user). Regardless of what user type you are, if you are not 
listed somehow in the access controls of the resource, you will be denied 
access. 


1.6.2 DSS ACL Managers and ACL Types 
An ACL Manager implements ACLs for a specific set of objects by defining a 
permission set unique to each object type it controls. DSS takes advantage 
of this DCE feature as it provides greater scope for controlling permission 
and access to different types of resources. For example, the actions an 
account can perform on an account definition in the registry are different 
from those for a file resource. While each DSS service type (Security, 
Directory, Time and the File and Print servers) has its own unique set of 
ACL Managers, we describe only the File and Print sharing services. 


DSS File and Print servers define and support the following types of ACL 
Managers to control access to the following types of resources: 


« Directory 

- File 

¢ Print 

- Serial Device 

* Named Pipe 

¢ Removable Media 
¢ Server 

¢ Audit 


The DSS ACL model is based on an object-oriented file system approach 
similar to HPFS386. However, DSS enhances the ACL function by defining 
different ACL types depending on whether the resource is a simple object or 
a container. Containers are objects that hold other objects. The objects they 
hold can themselves be either simple objects or containers. Simple objects 
do not hold other objects. Although any DSS component can have objects 
and containers, the simplest and most common illustration is the file 
system. In the file system, there are files and directories. The files are 
simple objects, and the directories are containers. The directories can hold 
simple objects (files) and other containers (subdirectories). 


A simple object only has an object ACL. A container object has an object, 
an initial container, and an initial object ACL: 
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Object ACLs 


Initial Object ACL 


Initial Container ACL 


This ACL defines the list of entities which are 
allowed access to this particular object. This list 
is inherited from the Initial Object ACL of its 
container when the object is created. 


Determines the default object ACLs for simple 
objects created within a container, as well as the 
Initial Object ACL for any container created 
within a container. For example, the file system 
Initial Object ACL for a directory specifies the 
default ACL for files created within that directory. 


Defines what ACLs a new child-container will 
inherit from its parent. This determines the 
default object ACL, as well as the Initial 
Container ACL for containers created within a 
container. For example, the file system Initial 
Container ACL for a directory specifies the 
default object ACL for subdirectories created 
within that directory. 


1.6.2.1 DSS ACL Entries and Resource Permissions 

ACLs are associated with individual resources and consist of multiple 
entries. Each entry specifies the type of operations a principal (user or 
group) is permitted to perform on the resource to which the ACL is attached. 
An ACL entry consists of an entry type, an identifier (optional depending on 
the entry type) and a permission set. 


DSS implements the DCE ACL facility to protect and control access to 
resources. The ACL entry format outlined below lists only those ACL entry 
types supported by the DSS File and Print sharing Server: 


user Account in the default cell 

group Group in the default cell 

other_obj All principals in the default cell 

foreign_user Account in a foreign cell 

foreign_group Group in a foreign cell 

foreign_other Account in a foreign cell not listed in foreign_user or 


foreign_group 


any_other All local or foreign principals that do not match any 
other entry above 
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mask_obj Specifies a filter, or mask, to control the permissions 


granted. Useful for temporarily restricting access 
without changing all the ACLS with an associated 
resource. 


authenticated Any account which has not been authenticated by a DCE 


security server 


The DSS File and Print server supports permissions for the following types 
of resources: 


Directories 

Files 

Removable Media 
Serial Devices 
Printers 

Servers 

Named Pipes 
Audit Records 


For a description of the permission sets for each of these resources, search 


for 


“valid permissions” in the online DSS Administrator's Reference. 


1.6.3 Access Control Checking Sequence 
When a user or process attempts to access a resource, such as reading or 
deleting a file, DSS must first check the user’s authorization, as described in 
1.6.1, “Authorization” on page 20. The actual sequence for checking access 
controls is as follows: 


1. 


The ACL Manager on the server of the resource being accessed looks at 
the EPAC of the user requesting access. Once the user ID and group 
memberships (the list of group memberships is also known as the 
project list) are determined, the ACL Manager checks the ACL entries of 
the resource being requested. 


. The user-specific access controls are checked first, in the following 


order: 
a. user 
b. foreign_user 


Note: The user_obj entry, normally checked before the user entry, 
is not used in the DSS File and Print server. 


If the user ID appears in the user or foreign_user entries, the search 
stops at the first match and the permissions for that entry are filtered 
through the mask_obj. The resulting permissions are checked against 
the request, which is then granted or denied. 
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As in OS/2 LAN Server, user permissions take precedence over any 
group permissions. If the user ID does not appear in the user or 
foreign_user ACLs, the group ACLs are checked, as described in the 
next step. 


. The group ACLs are now checked. The ACL Manager looks for groups 


that are listed in the user’s EPAC and in the resource ACL entries. The 
checking order is as follows: 


a. group 
b. foreign_group 


Note: The group_obj entry, normally checked before the group 
entry, is not used in the DSS File and Print server. 


The permissions for each matching group are gathered and the 
permissions for each matching group are ORed. These accumulated 
permissions are then filtered through the mask_obj. The resulting 
permissions are checked against the request, which is then granted or 
denied. 


If there were no matching groups found, the ACL Manager proceeds to 
the next step. 


. In the same manner, the ACL Manager checks the following for a match: 


a. foreign_other 
b. any_other 


The mask_obj is also applied to the permissions if a user ID match is 
found. If no match is found in foreign_other or any_other, the access 
request is denied. 
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Chapter 2. Planning Your DSS Environment 


Before you plan your DSS environment, we recommend that you read 
Appendix A, “Introduction to DCE” on page 173, before continuing with this 
chapter, even if you are already familiar with the basic concepts of the 
Distributed Computing Environment (DCE). 


Planning the DSS environment is critical to its successful installation, 
operation and daily management. Poor installation planning may result in a 
failed installation or poor performance that may ultimately require a 
redesign of the cell and may cause unnecessary downtime for end-users. 
Installing DSS over your existing OS/2 LAN Server or OS/2 Warp Server 
infrastructure will achieve the benefits of consolidation of your OS/2 LAN 
Server domains. However, it may not provide the performance and 
redundancy offered by a detailed cell design. This chapter looks at some 
important aspects that must be considered in the planning of any DSS cell, 
but we recommend that you read the redbook titled DCE Cell Design 
Considerations and, if necessary, obtain appropriately skilled consultation, 
such as that from IBM Global Services. 


2.1 System Requirements 


As a minimum, the DSS cell requires one or more workstations installed 
with a Security Server, a Directory Server, and a DSS Domain Controller. 
One or more Time Servers are recommended, but may not be required. 

Additional DSS Servers may also be installed in the cell for resilience or 
performance. 


The following tables list the recommended minimum and preferred 
hardware environment for DSS Clients and Servers. To administer a DSS 
cell, you must have an OS/2 DSS Client. It is recommended that DSS Clients 
to be used as administrative workstations have at least 24 MB of RAM. 





Table 1 (Page 1 of 2). Minimum DSS Hardware Environments 


DSS Workstation Type Minimum Minimum Minimum 
CPU System RAM System 
DASD 


DSS OS/2 client (slim) 486 33 MHz 16 MB 





DSS OS/2 Full/Admin client 486 66 MHz 24 MB 





DSS Additional Server 486 33 MHz 24 MB 


DSS Security Server 486 33 MHz 24 MB 400 MB 
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Table 1 (Page 2 of 2). Minimum DSS Hardware Environments 











DSS Workstation Type Minimum Minimum Minimum 

CPU System RAM System 
DASD 

DSS Directory Server 486 33 MHz 24 MB 400 MB 

DSS Security Server and 486 33 MHz 

Directory Server 

DSS Domain Controller 486 33 MHz 

DSS Domain Controller and 486 33 MHz 


any combination of Directory 
and Security Servers 








Table 2. Recommended DSS Hardware Environments 




















DSS WORKSTATION TYPE CPU SPEED SYSTEM SYSTEM 
RAM DASD 
DSS OS/2 Client (Slim) 486 66 MHz + 16 MB Over 
+ 300 MB 
DSS OS/2 Full/Admin client 5x86-90 MHz + 32 MB Over 
+ 300 MB 
DSS Additional Server 5x86-90 MHz + 32 MB 
DSS Security Server 5x86-90 MHz + 32 MB 
DSS Directory Server 5x86-90 MHz + 32 MB 
DSS Security Server and 5x86-90 MHz + 32 MB 400 MB 
Directory Server 
DSS Domain Controller 5x86-90 MHz + 32 MB Over 
400 MB 
DSS Domain Controller and any 5x86-90 MHz + 48 MB Over 
combination of Directory and 400 MB 


Security Servers 














Note: 


1. If a DSS Domain Controller is also acting as a file server, 
additional allowance must be made for any memory allocated as 
cache. 


2. DSS Directory and Security Servers cache the contents of the 
Cell Directory Service (CDS) database and the registry on startup. 
For large cells, it is likely that some of this cache will be swapped 
to disk. In general, it is our recommendation that as much 
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system RAM as possible is used on DSS Directory and Security 
Servers. 


3. If aDSS Master Security Server is selected, the password 
strength and password synchronization functions must also be 
selected. For more information on these functions, refer to 6.2, 
“Password Management Considerations” on page 168. 


2.1.1 Supported Network Adapters 
For the latest list of adapters supported for use with the Directory and 
Security Server for OS/2 Warp, please refer to the following IBM external 
Web site: 


http: //www.austin.ibm.com/pspinfo/nic.htm 


The current adapter listing at time of printing is also included in Table 10 on 
page 211 for your convenience. 


2.1.2 National Language Support 
The Directory and Security Server for OS/2 Warp is translated into the 
following languages: 


¢ Brazilian Portuguese 
* Canadian French 

¢ Danish 

¢ Dutch 

¢ English 

¢ Finnish 

¢ French 

¢ German 

¢ Italian 

* Japanese 

* Korean 

¢ Norwegian 

« Simplified Chinese 
* Spanish 

* Swedish 

- Traditional Chinese 


Note: UK English and Portuguese are also provided by implementing the 
DSS English on top of the country-specific Warp Version 3. 


2.1.3 Software Requirements 


This section covers the software requirements for your configuration. The 
minimum software for the various DSS components is one of the following: 
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Table 3. Software Prerequisites for DSS 





Upgrade To Prerequisites 


DSS OS/2 Client OS/2 Warp Connect File and Print 
Client + latest OS/2 V3 FixPak (at 
least FP21) 


LS 4.0 OS/2 Client and OS/2 Warp V3 
+ latest OS/2 V3 FixPak (at least 
FP21) 





DSS Security, Directory or Time LS 4.0 Server and OS/2 Warp V3 + 
Server, DSS Primary or Backup latest OS/2 V3 FixPak (at least FP21) 


Seale enea g SECU OR OS/2 Warp Server with File and Print 
yee Services + latest OS/2 V3 FixPak (at 
least FP21) 











Notes: 


1. The minimum FixPak required is FixPak 21. This is shipped with DSS in 
most countries. We strongly recommend that you apply the /atest 
FixPak. 


2. For OS/2 LAN Server Version 3 clients or earlier, you must first upgrade 
to either the OS/2 LAN Server Version 4 client or the OS/2 Warp 
Connect Client before upgrading to the DSS Client. 


3. Installation over Warp Version 4 is currently not supported as of the 
publication of this redbook. As of June 1997, IBM is investigating the 
possible support of DSS over Warp 4 and also over OS/2 Warp Server 
SMP. Please check with your IBM support representative to see if these 
environments are now supported. To force the installation over Warp 4, 
set the following environment variable to bypass the check for a 
prerequisite FixPak: 


SET DSSFPCHK=1 





2.2 Planning DSS Servers and Clients 


A Directory and Security Server for OS/2 Warp cell requires the following 
core servers: 


« Master Security Server 
¢ Initial Directory Server 
¢ DSS Domain Controller 


The DSS cell is not operational until all three servers have been installed 


and are running. (A regular DCE cell requires only a Master Security Server 
and an Initial Directory Server to be up and running). 
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These core servers can be installed on separate machines, or they can be 
combined onto one or two machines. For example, some environments may 
have a Security Server on machine 1, a Directory Server on machine 2, and 
a DSS Domain Controller on machine 3. Others, perhaps in smaller 
environments or for testing purposes, may install all three core services on 
one machine. 


We recommend that the initial Cell Directory Server, and especially the 
Master Security Server, are installed on separate, dedicated machines, 
preferably on the most powerful, resilient hardware available. 


The Directory and Security Server for OS/2 Warp is, of course, compatible 
with other implementations of OSF DCE 1.1. If you are installing into an 
existing DCE cell, then the core DCE services will already be available, 
probably running on a platform other than OS/2. In this case you can 
migrate your OS/2 LAN Server domains into the existing cell. Please see 
6.3, “Adding DSS to an Existing DCE Cell” on page 170 for installation 
considerations in this scenario. 


Alternatively, if you are installing into an environment where DCE has not 
been implemented, but there are existing AIX Servers available, you may 
wish to install IBM DSS for AIX and configure your core servers on this 
platform. 


Once the three core servers are up and running, additional servers may be 
added to the cell at any time. The following types of servers may also exist 
in the cell: 


- DSS Security Replica(s) 

¢ DSS Directory Replica(s) 

« Time Server(s) 

¢ DSS Additional Server(s) 

¢ DSS Backup Domain Controller(s) 

* OS/2 LAN Server V4 or OS/2 Warp Server Backup Domain Controller(s) 
* OS/2 LAN Server V4 or OS/2 Warp Server Additional Server(s) 


2.2.1 Planning Migration to DSS 
Because of the high degree of compatibility between DSS and existing OS/2 
LAN Server clients and servers, it is possible to carry out a staged, ora 
partial, migration to a DSS environment. As more of the existing 
environment is migrated, there is obviously an increasing cost in terms of 
the number of software licenses and the amount of work involved, but the 
benefits gained also increase. The following stages of migration are 
possible : 


1. Migrate only Domain Controllers to DSS. 
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2. Migrate Domain Controllers, Backup Domain Controllers, and all 
Additional Servers to DSS. 


3. Migrate all servers and all OS/2 clients to DSS. 


Notes: 


1. At the writing of this redbook, the upgrade of the file and print services 
on a server from OS/2 LAN Server or OS/2 Warp Server to DSS File and 
Print Services is a no-charge item. Only DSS Directory and Security 
Servers installed are chargeable. There is a use-based feature (UBF) 
chargeable for every client that accesses the DSS cell. This includes 
legacy DOS/Windows and OS/2 clients. 


2. When migrating a Domain Controller or a Backup Domain Controller to 
DSS, the RGYSYNC service and a full Security Replica are installed by 
default (this replica is required by the RGYSYNC service). In this case, 
the Security Replica installed is a no-charge item. Any other installation 
of a Security Replica (on an additional server or as a stand-alone 
server) is a chargeable item. 


3. If the domain is at a location remote from the core servers of the cell, 
then although a Security Replica is installed by default as part of the 
migration of the Domain Controller, it may also be beneficial to install a 
directory replica at the remote site to ensure fast, local response times. 
If this Directory Server is also to be installed on the Domain Controller, 
then the hardware specification of this machine must be adequate. 


2.2.1.1 Migration Stage One - Domain Controllers Only 

To migrate an existing OS/2 LAN Server or OS/2 Warp Server domain into 
DSS, then as a minimum, only the DSS File and Print services code needs to 
be installed on the Domain Controller of that domain. All existing clients will 
be able to log on and access resources anywhere in the cell with a single 
user ID and password. User IDs, groups and resources will all be migrated 
into the cell registry and directory, where they can be centrally 
administered, if required. Migrating only the Domain Controllers is a valid 
and simple step for the company that wishes solely to obtain the benefits of 
centralized administration for all their OS/2 LAN Server domains and a 
single user ID and password for all their users. However, the following 
points must be considered: 


¢ If the existing domain administrator will be required to carry out 
administration of the migrated resource domain, then at least one 
workstation will need to be updated to the DSS Client. 


* Because the additional servers have not been migrated, these servers 
will still use a NET.ACC file. In order for users in a resource domain to 
be able to access resources in another resource domain, they, or a 
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group of which they are a member, must be associated with that 
domain. Association of a user with another resource domain is a simple 
drag-and-drop operation from the GUI, or can be done by use of the NET 
USER command, but this may be a significant task if there are many 
hundreds of users and groups, each requiring access to multiple 
resource domains. One way to circumvent this is to define 

cross-domain aliases and utilize the access controls of the GUEST ID, as 
was possible in OS/2 LAN Server and OS/2 Warp Server. 


The limitations of the NET.ACC file still apply in the migrated resource 
domain (see 1.3.3, “Scalability” on page 4 for further details). This 
means there are still finite limits to the size of any single resource 
domain. Also, if very large numbers of users are associated with a 
single resource domain, the workload of the RGYSYNC, DIRSYNC and 
NETLOGON services may become excessive. 


Because of the limitations of the OS/2 LAN Server Application 
Programming Interface (API), users of legacy clients can only receive 
logon assignments from the resource domain into which they are 
logging on. If cross-resource domain logon assignments are necessary, 
then they will need to be set up as cross-domain aliases. This could 
represent a significant administrative task (cross-resource domain 
access can also be effectively managed by the use of logon scripts). 


When a legacy client logs on, the flows between the client and the 
Domain Controller handling the logon are standard OS/2 LAN Server 
Server Message Block (SMB) flows. The OS/2 LAN Server flow includes 
the passing of the doubly-encrypted password. In this case, the benefit 
of a full, secure Kerberos-based DSS login is not being realized. 


A legacy client cannot access resources in a foreign cell unless a new 
account has been created for it in the foreign cell. 


2.2.1.2 Migration Stage Two - All Servers in the Domain Migrated to 
DSS 

Once all servers in the resource domain have been migrated to DSS, then 
the NET.ACC file is no longer needed. An attempt by a legacy client to 
logon to or connect to a DSS Server will always result in the DSS obtaining 
authentication information from a Security Replica on behalf of the client. 


Points to consider: 


If the existing domain administrator will be required to carry out 
administration of the migrated resource domain, then at least one 
workstation will need to be updated to the DSS Client. 


A user does not need to be associated with this domain in order to be 
able to access resources within it. 
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¢ There are now no theoretical limits to the size of the resource domain. 


* Because of the limitations of the OS/2 LAN Server API, a user of a 
legacy client can only receive logon assignments from the resource 
domain into which he is logging on. If cross-resource domain logon 
assignments are necessary, then they will need to be set up as 
cross-domain aliases. This could represent a significant administrative 
task (cross-resource domain access can also be effectively managed by 
the use of logon scripts—see 5.5.5, “Logon Assignments for Mobile 
Users” on page 141 for further details). 


« When a legacy client logs on, the flows between the client and the 
Domain Controller handling the logon are standard OS/2 LAN Server 
SMB flows. The OS/2 LAN Server flow includes the passing of the 
doubly-encrypted password. In this case, the benefit of a full, secure 
Kerberos-based DSS login is not being realized. 


* It is still necessary to run the DCDB Replicator service if there is a 
Backup Domain Controller in the domain. The DIRSYNC service will not 
run on a DSS Backup Domain Controller which still needs to receive 
updates to its DCDB from the nearest DSS Directory Server. Legacy 
clients still need to obtain their logon assignments and resolve aliases 
from the DCDB. 


* A legacy client can not access resources in a foreign cell unless a new 
account has been created for it in the foreign cell. 


Note: OS/2 LAN Server V3.0 (and OS/2 LAN Server V4.0 without FixPak) 
clients, although they can logon to a DSS resource domain, make redirected 
1/O calls (to \DCDB\USERS\username\USER.L and USER.S) to read logon 
assignments and public applications, rather than issuing API calls, as do 
OS/2 LAN Server 4.0 clients with APAR 1C13565 applied. If your servers are 
migrated to DSS and your legacy clients are at OS/2 LAN Server V4 with 
APAR 1C13565 or later, you can stop the RGYSYNC service. 


2.2.1.3 Migration Stage Three - All Servers and Clients Upgraded to 
DSS 

At this stage, clients no longer log on to a resource domain, but just directly 
to the cell. Their logon is handled directly by a Security Server: 


¢ Administration can be carried out on any workstation. 


« Any user in the cell can access resources in any resource domain 
without being associated to the resource domain. 


¢ There are no theoretical limits to the size of the resource domain. 


« A user can receive logon assignments from any resource domain in the 
cell. 
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* The client benefits from end-to-end DCE security whenever logging on or 
connecting to a DSS Server. 


¢« The client can use resources of another cell if proper permission in the 
foreign cell and a proper trust relationship between the cells exists. 


2.2.2 Planning Resource Domains 

As the size of a DSS cell grows, it is important that a structured namespace 
is maintained, so that resources can be easily located and managed. In 
addition, it is necessary to partition these resources into segments that can 
be easily administered. In a large cell, it is likely that various groups of 
users will require administration rights over different sections of the cell. 
Resource domains (the corresponding objects in the CDS are also known as 
realms) address these requirements in two ways: 


¢ By defining an administrative collection of resources and servers within 
the cell 


¢ By defining a hierarchical relationship between the resource domains in 
the cell 


When accessing resources in a cell, the resource domain name is used as 
part of the location specification for the resource. For example, logon 
assignments are now stored in the following format: 


X: OS2APPS@OCLABG/.../oclabcell 


A user with this assignment will get an X: drive at logon, which is directed 
to the OS2APPS alias in the OCLAB resource domain (in the oclabcel] cell). 


When the first DSS Domain Controller (one of the three core servers) is 
installed into the cell, then TWO resource domains are created - a root 

resource domain and a resource domain with the name of the OS/2 LAN 
Server domain before migration (say DOM1). 


DOM1 is a child of the root resource domain. The cell administrator ID, 
which was defined during installation of the core servers, has administration 
rights to the root resource domain and to all children of the root, which 
means that, by default, the cell administrator has administration rights to all 
resource domains in the cell. The old OS/2 LAN Server administrator of the 
DOM1 domain, once migrated, now has rights to the DOM1 resource domain 
only. The administrator of a resource domain can only administer 
resources in that domain, not in other resource domains, unless an 
administrative relationship is established. 


Note: In DSS the administrator role is not equivalent to the ADMIN role in 
OS/2 LAN Server, where the administrator automatically has access rights 
to all resources in the OS/2 LAN Server domain, bypassing ACL security 
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checking. In DSS, the former OS/2 LAN Server administrators are members 
of a group, (realms/DOM1/admins for example), which, by default, appears in 
the ACL for every resource in the resource domain with full access rights. 


2.2.2.1 Example Resource Domain Relationships 

Consider a company structured with a head office domain (HODOM) and 
three branch office domains (BRANCH_A, BRANCH_B and BRANCH_C). 
There are several ways in which the resource domain relationship could be 
structured: 


root 





HODOM BRANCH_A BRANCH_B BRANCH_C 


Figure 4. Resource Domain Flat Model 


34 


1. Flat model—Figure 4 shows all four domains migrated as children of the 
root resource domain. This is the default model for DSS. At installation 
time, root (the default) is selected as the parent resource domain for 
each of the Domain Controllers. The cell administrator has 
administration rights over all four resource domains, but each of the old 
OS/2 LAN Server administrators now only has partial administration 
rights to their own resource domain. This model may well be 
appropriate if each of the sites has their own skilled administration staff, 
and there are no plans to change this. Note that only the cell 
administrator can add or remove user IDs for the cell. 
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root 


HODOM 








BRANCH_A BRANCH_B BRANCH_C 


Figure 5. Resource Domain Hierarchical Model 


2. Hierarchical model—Figure 5 shows the HODOM Domain Controller 
migrated with a parent resource domain of root, but BRANCH_A, 
BRANCH_B and BRANCH © are all migrated with a parent resource 
domain of HODOM. Each branch DSS administrator can still manage 
their local users and resources, but the administrator at the Home Office 
can also manage any of the branch office resource domains if necessary 


(as can the cell administrator). 





root 
HODOM 
| 
BRANCH_A REGDOM 
BRANCH_B BRANCH_C 


Figure 6. Resource Domain Modified Hierarchical Model 


3. Hierarchical model with empty resource domain—Figure 6 shows 
HODOM has been migrated with a parent of root. BRANCH_A has been 
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migrated with a parent of HODOM. A new resource domain has been 
created, REGDOM, also with a parent of HODOM. There are no servers 
defined in REGDOM. BRANCH_B and BRANCH _C are both installed 
with a parent of REGDOM. Now, as in Figure 5 on page 35, the Home 
Office administrator can manage any branch office resource, and the 
branch administrator of each of the resource domains can manage their 
own resources. However, if we now associate a user ID as 
administrator of the REGDOM resource domain, then he is able to 
administer in both BRANCH_B and BRANCH _C resource domains. 


As shown in Example 3 above, resource domains do not need to have any 
servers defined in them and can be used solely for setting up of the 
hierarchical model. However, if servers are to be added to an ‘empty’ 
resource domain, then the first server to be added must be a Domain 
Controller. 


2.2.2.2 Changing the Resource Domain Structure 

DSS allows for the relationship between resource domains to be easily 
changed. The RESDOMMV, RESDOMMG and RESDOMDL commands can be used to 
move, merge or delete any resource domain. The RESDOMMG command could 
be used, for example, in a scenario where a Home Office site has a number 
of existing OS/2 LAN Server domains, which, after migration would be more 
sensibly managed as a single resource domain. For more information about 
these commands, refer to the online Commands and Utilities Guide. 


2.2.3 Deciding on the Administration Model 
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The decision of how to plan the structure of your resource domains and the 
resulting administration model depends on where the skilled personnel are 
located. The flexibility of DSS allows for completely centralized 
administration, splitting administration into small groups of resources, or 
any combination of the two. 


A centralized administration structure is very beneficial for environments 
that have many remote offices and do not want to have dedicated support 
staff at each site. If a company has large regional offices with competent 
staff, then the planners may wish to continue the control of resources, 
unchanged, at the regional level. However, even in this case, it is helpful to 
define an administrator at the root level who can administer any regional 
office for emergency purposes. 


Note that every DSS administrator in the cell should be equipped with a Full 
DSS Client system. The level of administration that can be performed by 
legacy clients depends upon the level of the client software. For example, 
OS/2 LAN Server Version 3.x clients are able to change their own password. 
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OS/2 LAN Server Version 4.x and OS/2 Warp Server clients are also able to 
administer their own logon assignments, private applications, and 
application selector lists. All other administration in a DSS network must be 
done at a DSS Client system with an ID that has sufficient authority for the 
given task. 


2.2.4 Planning DSS Server Replication 
Once you configure your core DSS Servers, you will probably need a certain 
number of both Security and Directory Replica Servers in the cell for both 
availability and performance reasons. 


2.2.4.1 Security Replicas 

Every DSS Domain Controller will have, by default, a Security Replica 
installed, because it is a requirement of the RGYSYNC service. When all 
servers in a resource domain are migrated to DSS, then it is possible to 
stop the RGYSYNC service, but it is recommended that the Security Replica 
is maintained at the Domain Controller, certainly at remote sites, because 
this will mean that every client will have a nearby Security Replica. All 
Security Replicas are complete, read-only replicas of the master. The 
master is the only one that allows write updates. When a change to the 
Master Security Server is made, then updates to the replicas commence 
immediately, one replica at a time until all replicas have been updated. 


In the event of the Master Security Server becoming unavailable for any 
reason, it is possible to upgrade any of the read-only Security Replicas to 
become the Master Security Server. It is also possible to switch roles 
between a Master and a Replica Security Server. For further details on this 
procedure, please refer to Troubleshooting Procedures in the DCE 
Administrators Reference. 


By default, the method used by DSS Clients and Servers to locate a DSS 
Security Server is based on a random selection of bindings. In many 
environments, there will be a need for more control over the search order of 
Security Servers in the DSS cell. Such control would improve the logon 
performance of DSS Clients since a Security Server closest to the DSS 
Client would be given preference over a Security Server located over a 
WAN. This control is also important for DSS File and Print Servers since 
these servers contact a Security Server to authenticate legacy users during 
session establishment. Giving preference to a Security Server located on 
the same LAN as the File and Print Server will improve the server’s logon 
performance and session-establishment performance. 


Please refer to 5.6.2.1, “Setting the Preferred Security Replica” on page 152 
for the steps on setting up the preferred Security Replica. 
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2.2.4.2 Directory Replicas 

Unlike a Security Replica, a Directory Replica is not necessarily a complete 
copy of the Initial Directory Server. It is possible to split the CDS (or 
namespace) across several Directory Replicas; so for example, it would be 
possible to create an initial Directory Server at a Home Office site (as 

in Figure 7 on page 40) which contained details of all servers and 
resources at that site, and a Directory Replica at each branch office which 
contains all servers and resources at that remote site. Only one read/write 
(master) copy of each partition of the CDS can exist, but there can be 
multiple read-only replicas. Splitting the CDS may be done to reduce the 
memory requirement on any one server (the CDS is cached at server start 
up), but it is recommended that whenever possible, for simplicity, an initial 
Directory Replica with a complete CDS is set up with at least one complete 
replica, so that the roles may be switched in the event of a failure. 


A company may want to add Directory Replicas in remote offices if there are 
many resources local to that office. This way, if the WAN link to a regional 
or headquarters office is down, the employees at that remote site can still 
discover and use resources locally, because the Directory Replica can 
provide the location of the local resources. 


When a Directory Replica is installed, only the root directory is initially 
copied from the Initial Directory Server. Other branches of the directory 
tree to be copied to the replica must be copied manually by the 
administrator. 


When an update is made to the Master Replica, the process of 
synchronizing with other replicas is not immediate, as in the case of 
Security Replicas, but uses a process called skulking, which is a periodic 
distribution of recent modifications. It is possible, however, to synchronize 
the replica set rather than waiting for the next scheduled skulk by use of the 
following command: 


dcecp -c directory synchronize 


Please see the online DCE Administration Command Reference and DCE 
Administrators Reference for further details of managing the CDS. 


2.2.5 Time Services 
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Time is very important in the DSS cell. The authentication process used by 
DSS is based upon an exchange of, and the granting of, tickets which 
include a timestamp and which have a specified lifetime. If the network time 
skew factor becomes too big, it might happen that an unexpired ticket might 
be regarded as invalid, and an expired ticket may be considered valid. 
Logon from a DSS Client may fail if the client’s clock is five minutes or more 
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skewed from that of the server and synchronization of the DSS Servers may 
stop working. Also, the directory skulk process described earlier uses 
timestamps (obtained from Distributed Time Service (DTS) or the local OS/2 
time) to decide when to propagate changes. 


Because of these potential problems, it is necessary to ensure that time is 
kept synchronized on all DSS Servers and Clients. This is the function 
provided by DTS. 


In theory, the system clocks on all systems in the world store the same time 
value in their clock registers. This time is known as Universal Time 
Coordinated (UTC) and is the time to which all DTS Servers attempt to 
synchronize. However, the time displayed by a server’s system clock will 
vary from the UTC, depending upon the Time Zone (TZ) setting of the 
workstation (see 4.1.1, “Pre-Installation Checklist” on page 78 for additional 
information on setting the Time Zone). This is how a DSS cell is able to 
cope with multiple time zones within a cell. 


How Time Services Works: Time Services consists of two main 
components—the Time Clerk and the Time Server. The Time Clerk keeps its 
local machine clock synchronized by asking as many Time Servers as are 
specified in its minservers attribute. For a DSS Client, the default for 
minservers is 1. If a Time Client cannot contact the minimum number of 
servers, it will not adjust its clock. 


The Time Server is a node that is designated to answer queries about time. 
Time Servers also query each other. For Time Servers, the minservers 
attribute defaults to 3, the server’s own time being one of them. In effect, 
every Time Server is frequently obtaining time values from two other Time 
Servers, taking a mean of these two values and its own system clock, and 
resetting its clock to this new value. Every client is frequently checking its 
own time with a Time Server. The overall result of this process is that the 
DTS Servers maintain an accurate time in an entire cell with minimal skew 
factors between systems. When installing a DSS Server, if a Time Server is 
not selected, a Time Clerk is installed by default. 


Note: If you have not done so, please read A.6, “Distributed Time Service” 
on page 189, for a description of the components and functions of the 
Distributed Time Service. 


2.2.5.1 Planning Time Services 

The minservers attribute specifies how many DTS Servers must supply time 
values in order for the local clock to be synchronized (don’t forget, for a 
Time Server, the local time value is also included, so for the default (three) 
minservers, only two other Time Servers need to be located). 
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Planning Time Servers in a cell involves: 


« Making sure that you have enough Time Servers in the cell to ensure 
synchronization of all DSS Servers 


* Making sure that you have the correct balance of Global and Courier 
Servers so that each LAN segment is synchronizing its time with other 
LAN segments across the WAN 


It is possible to change the value of minservers. The following dcecp 
command changes the value to 4: 


dcecp> dts modify -minservers 4 


Note: This change would need to be made on each individual system as 
necessary and the command would need to be reissued each time the DTS 
is started on that system. 


Consider the simple cell example in Figure 7. 


Home Office 


Directory 





BRANCH_A BRANCH_B BRANCH_C 


Figure 7. Example Environment Time Server Configuration 
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The Home Office LAN (HODOM resource domain) is connected to three 
remote branch LANs through WAN links (BRANCH_A, BRANCH_B, 
BRANCH_C). The Home Office is a large site which contains the DCE core 
servers and four Time Servers. BRANCH_A is a fairly large site, containing 
three Time Servers. BRANCH_B and BRANCH_C are small LANs, each with 
one DSS Domain Controller, which is also configured as a Time Server. 


The decision has been made that time will be considered to be correct at 
the Home Office site, and all other sites will synchronize with it. Of the four 
Time Servers here, two have been configured as Global Time Servers (these 
also act as Local Time Servers). All four servers have been assigned a 
Noncourier role. The four servers here will be constantly synchronizing 
among themselves, and the two which are Global Servers will advertise 
their presence in the CDS. 


At BRANCH_A, one of the Time Servers has been configured as a Global 
Courier. This server will always use one of the Global Servers from the 
Home Office for one of its three time values. It will also advertise its 
presence in the CDS. One of the other two Time Servers is assigned a 
Backup Courier role. If for any reason the Global Courier Server is not 
available, then the Backup Courier will take over importing time from one of 
the Home Office Global Servers. 


At the two small branches, the Courier Time Servers will be constantly 
obtaining time values from two of the three Global Time Servers available. 


Time Servers, by default, synchronize themselves approximately every 24 
hours. If you wish to change this interval, you can use the following dcecp 
command. This example changes the synchronization interval to 12 hours: 


dcecp> dts modify -syncinterval +0-12:00:00.000 


In our example, all servers will now be synchronizing themselves with time 
at Home Office. Of course, it is likely that the time on our Home Office 
Servers may eventually drift away from correct time. In this case, we will 
need to periodically correct the time manually on these servers by using the 
dcecp> clock set command. Further information on this command may be 
found in the DCE Administration Command Reference. 


As an alternative, it is possible to use an External Time Provider to prevent 
the whole cell from drifting away from correct time. There are several 
devices that are able to obtain UTC values by radio, satellite or telephone. 
An Internet Network Time Protocol (NTP) Server can also be the time 
provider. One or more DTS Servers can synchronize with time providers by 
means of the TPI (Time Provider Interface) component of DCE. The rest of 
the cell can then use DTS to synchronize with these Time Servers. For 
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more information on using the Time Provider Interface, refer to the online 
DCE Application Development Guide - Core in the \TOOLKIT\PUBS directory 
on the Directory and Security Server for OS/2 Warp CD-ROM. 


2.2.6 Selecting Network Protocols 
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DSS Clients and Servers have both a DCE and an OS/2 LAN Server 
component. The DCE component is used for server-to-server 
communications and certain DSS Client to Server communications, such as 
authentication. The OS/2 LAN Server component is used when the DSS 
Server communicates with legacy clients and servers, or when the DSS 
Client is using file and print resources on a DSS Server. 


The choice of protocol needs to be considered for: 
¢ The DCE component of DSS Clients and Servers 
* The OS/2 LAN Server component of DSS Clients and Servers (and 


legacy clients and servers) 


DCE was designed for use over a TCP/IP network. It supports the NetBIOS 
protocol by using the NetBIOS sockets support provided by Multiprotocol 
Transport Services (MPTS). 
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Figure 8. DSS Installation - Protocols Panel 


The Protocols panel of the DSS Installation notebook presents you with the 
protocol options for the DCE component. You are given the choice of using 
TCP/IP (connectionless, connection-oriented), NetBIOS or both. In our 
experience you should select one or the other of the two protocols. It is 
also possible that connectionless TCP/IP protocol may be unsupported 
and/or undesirable in a router network. In general, we recommend that you 
select the TCP/IP protocol (enable both connectionless and 
connection-oriented) and do not select NetBIOS Sockets. Remember, this 
does not affect the protocols used by the File and Print component (these 
are specified in the Adapter and Protocol Services line in Figure 8). 


Note: If your Master Security Server is not an OS/2 DSS Server, you must 
select the TCP/IP protocol on this panel. This must also be selected 
for DSS clients who will administer the cell. 
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To understand the protocols and flows in more detail, please refer to 
Figure 9 on page 44. 
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Figure 9. DSS Protocol Architecture 


Protocols for the OS/2 LAN Server component of DSS (and legacy clients 
and servers) are configured directly in MPTS. The choice here is between 
using native NetBIOS and NetBIOS over TCP/IP (TCPBEUI). Consider also 
configuring both protocols so that clients can benefit from the faster 
NetBIOS protocol for accessing local servers and using TCPBEUI to access 
servers across WAN links. 


If you currently have an OS/2 LAN Server or Warp Server network using 
NetBIOS and you intend to migrate to both DSS and TCPBEUI, then it is 
strongly recommended that you migrate to, and prove, TCPBEUI in your 
OS/2 LAN Server environment first, before migrating to DSS. 
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Note: There are many considerations when designing, and migrating to, a 
TCPBEUI implementation of Warp Server. We recommend that you refer to 
the redbook titled Inside OS/2 Warp Server, Volume 1, SG24-4602, for 
additional information about TCPBEUI. 


2.2.7 Planning DSS Clients 
The Directory and Security Server for OS/2 Warp supports resource access 
from any client that was also supported by OS/2 LAN Server Version 4 and 
OS/2 Warp Server. This includes non-IBM SMB-based clients, such as 
Artisoft LANtastic and Microsoft Windows 95 and Windows NT. DSS includes 
the capability to migrate an OS/2 client (only) to a DSS Client, which 
provides client support for working with DCE Directory, Security and Time 
Servers. The following operating systems platforms are supported for 
legacy clients: 


¢ MS and PC DOS 5.0 
- MS DOS 6.0, PC DOS 6.1, MS DOS 6.2, PC DOS 6.3 and PC DOS 7.0 


- Windows 3.1 (can be run in a RIPL environment, but only by connecting 
to and running Windows code after the RIPL process completes) 


¢ Windows for Workgroups 3.1 and 3.11 (no RIPL) 


¢ Windows NT (in the same manner as it is supported in OS/2 Warp 
Server) 


* OS/2 2.11 plus latest service packs 
* OS/2 3.0 Warp (with Win-OS/2) plus the latest FixPak 
* OS/2 3.0 Warp for Windows plus the latest FixPak 
¢ OS/2 Warp Connect plus the latest FixPak 
* OS/2 Warp Connect for Windows plus the latest FixPak 
Note: Other SMB-based clients should still work with DSS, but have not 


been officially tested. 


Although the Directory and Security Server for OS/2 Warp does not include 
DSS Clients for non-OS/2 requesters, these clients can still fully participate 
in accessing file and print resources, just as they did in the OS/2 LAN 
Server environment. Before migration, a client would access a resource in 
an OS/2 LAN Server domain. Now, they would access the same resource, 
which is in a DSS resource domain within the cell. The DSS Domain 
Controller includes full support for legacy clients in addition to its integration 
with the DCE cell. 
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2.2.7.1. Administration 

There are varying levels of administration available to the different OS/2 
LAN Server clients that exist in the DSS cell. As a result, it is very important 
that administration be defined in terms of the following administration 
functions: 


User/Group - the ability to add/delete/update user and group definitions 
in the cell 


Resource Definition - the ability to add/delete/update alias and public 
application definitions in the cell 


Server - the ability to invoke server administration functions (such as net 
share, net statistics, net audit, net error) on the server 


Resource ACL - the ability to update the ACLs for resources on a server 
(this does not include the ability to update ACLs in the CDS or the 
registry). 

Password Change - the ability to change one’s own password in the 
DSS cell. 


User Type - the ability for non-admin users to update their own logon 
assignments, private applications, application selector list, logon script, 
and so on. 


The cell administration capability of each client in the DSS cell is shown 
below. 





Table 4. Administration Capabilities by Client Version 
































Administration Function OS/2 LS 3.x Client OS/2 LS 4.0 Client OS/2 DSS Client 
User/Group No No Yes 

Resource Definition No No Yes 

Server Yes! Yes! Yes! 

Resource ACL Yes/No2 Yes/No2 Yes3 

Password Change Yes Yes Yes 

User-type No Yes Yes 

Note: 


1. Will be able to administer both DSS and OS/2 LAN Servers if permissions allow 
2. Will be able to administer ACLs on legacy OS/2 LAN Servers but not on DSS Servers 
3. Will be able to administer ACLs on both legacy OS/2 LAN Servers and DSS Servers 





Since the only native DSS Client is for the OS/2 platform, let’s discuss it in 
more detail. There are two OS/2 DSS client types—the full client and the 
slim client. 
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2.2.7.2 Full Client 

The DSS OS/2 full client includes DCE client processes for interacting with 
the Directory Server, Security Server, Time Server and RPC Servers (such 
as DCE Application Servers). The following processes (sometimes called 
daemons) are included: 


dced The DCE client daemon. It is responsible for providing Remote 
Procedure Call (RPC) support and also for client functions 
specific to security. It also starts other processes, such as the 
Endpoint Mapper Service, Security Validation Service and the 
System Management Service, which are used mainly by server 
applications. This process uses approximately 2-3 MB of RAM. 


cdsclerk The Cell Directory Service clerk. It is responsible for resolving 
location information for resources in the CDS namespace. This 
process uses approximately 1-2 MB of RAM. 


cdsadv The Cell Directory Service Advertiser. It allows DCE applications 
to communicate with the CDS Server daemon. It also starts the 
cdsclerk process. This process uses approximately 2 MB of 
RAM. 


dtsd The Distributed Time Service daemon. This process includes 
both Server and Client time functions, but is used as a client 
here. Although it is included in the full client, it is not installed 
by default. This process uses approximately 1.5MB of RAM. 


The client processes listed above (including dtsd) can use about 6 to 8 MB 
of additional client RAM. The full client is required in two situations: 


¢ DSS Administration 


OS/2 LAN Server administrators who were responsible for management 
of users, groups and resource definitions in the domain may now be 
defined as cell administrators or equivalent. 


¢ Supporting DCE Server-side applications 


DCE Server applications need to set up endpoints and advertise 
themselves in the namespace and respond to resource requests, thus 
requiring the processes provided with the full client. 


The full client is also defined in the cell registry and directory namespace 
during configuration. It is a full member of the DCE cell. Because of the 
changes to the registry and directory databases, the full client installation 
usually requires an administrator ID and password to be used during 
configuration. It is possible to split the full client installation into the cell 
configuration (which requires an administrator ID) and the local machine 
configuration (which does not require an administrator ID). 
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2.2.7.3 DSS Slim Client 

We recommend that the slim client be used for the majority of OS/2 DSS 
client installations. If fact, it is the default client type used in the installation 
process. Since the slim client loads only the critical processes needed for 
participating in the cell, there is considerably less workstation RAM 
overhead compared to the full client. Most clients require only the following 
functions: 


« Remote Procedure Calls (authenticated and unauthenticated) 
- DCE cell login 
* CDS name lookups 


Most RPC calls and the cell login do not require DCE processes; they are 
handled with runtime routines. A CDS name lookup requires the CDS clerk. 
Therefore, the only DCE process included in the slim client is the CDS clerk. 
Because of this, the DCE component of the slim client requires 
approximately 1-2 MB of RAM, much less than the 6-8 MB needed by the full 
client. 


Since the slim client does not require any entries in the cell registry or CDS 
namespace, an administrator ID is not required during slim client 
configuration. All processing is done local to the machine. 


2.3 Performance and Capacity Planning 


Although capacity planning and performance tuning can become very 
complex topics, our intent is to give you some tips and guidelines in these 
areas based on IBM developer and customer experience. We begin with 
restating some of the highlights of a white paper, DSS Configuration and 
Tuning, and also an article about DCE cell performance. We also describe 
the basic functions and usage of a Java-based Logon Capacity Estimator 
tool. 


Capacity planning and performance tuning are best approached iteratively. 
That is, make small changes, measure the improvement, and continue 
making changes until you reach your performance goals. It is important to 
decide on a realistic goal, specific to your environment. Companies often 
establish service levels for their end-users to state specifically what level of 
function and capability will be provided to them. 


2.3.1 Scalability Considerations 


48 


It is difficult to estimate how large your DSS cell can grow and still maintain 
satisfactory performance. There are many dependencies, such as the LAN 
and WAN bandwidth and layout, machine RAM and disk storage size, 
number of clients, and the frequency and complexity of transaction requests 
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by clients to servers. Because of this, there is no predefined maximum 
number of clients that a DSS cell can support. Some estimates from IBM 
development mention that DSS can support a 10000 user cell, and could go 
significantly higher. 


The number of replicas to install is very much dependent on the customer 
environment. However, there are some guidelines when deciding on large 
machines or many replicas. There was an article published in the 
November 1995 issue of AlXpert titled “DCE Cell Performance: High Water 
Marks”, written by Bob Russell, in the Systems Performance group at IBM 
Austin. His testing and analysis concluded the following key information: 


¢ CDS performance (number of lookups per second) is related to 
hardware capacity. An RS/6000 Model 990 performed much better than 
an Intel Pentium 90 MHz. 


¢ Increasing the number of CDS replicas is another way to support 
additional workload. In his testing, eight CDS replicas running on Intel 
486/33 systems performed equivalent to the RS/6000 Model 990. For 
many customers, this is a less expensive option which offers the same 
capacity. 


To view the full article, browse the following IBM Web site: 


http://developer.austin.ibm.com/sdp/library/aixpert/nov95/aixpert_nov95 dce.html 


2.3.2 Hints and Tips 


As customers implement DSS, there will be many different solutions based 
on each customer’s existing environment and specific end-user needs. 
Some customers may migrate completely to DCE-enabled systems, like DSS 
Clients and Servers, and others may need to integrate platforms such as 
legacy OS/2 and Windows systems with their DSS Servers. We have 
categorized this section for your convenience. To review the complete White 
Paper mentioned above, refer to the January/February 1997 issue of 
Personal Systems, which is available the following Web site: 


http://pscc.dfw.ibm.com/psmag/jan97/tech/dira.htm 


In general, when working with servers, make sure to use as much memory 
as possible (80-128 MB RAM is reasonable) and use at least Pentium-class 
processors. Test environments can be smaller, although performance will 
not be as good. For example, a ThinkPad 755C with 36 MB of RAM and 
functioning as a Security Server, Directory Server and DSS Domain 
Controller was swapping about 55 MB after all server functions were loaded. 
Performance of the DSS Administration GUI on this system was extremely 
slow due to excessive swapping. 
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2.3.2.1. Working with Clients 


Because of the power and function of DCE, your OS/2 DSS Clients will 
require more memory than the OS/2 LAN Server V4 or OS/2 Warp 
Server client. Refer to Table 1 on page 25 for more specific hardware 
recommendations. 


In general, you should continue to use the existing OS/2 LAN Server V4 
and OS/2 Warp Server clients. Upgrade to the DSS Client primarily for 
those involved in administering the DSS cell. 


Performance in DSS Clients is dependent mainly on the capability of the 
client hardware; so use at least 24 MB RAM and a Pentium-class 
processor. 


If doing DSS Administration, use at least 32 MB of RAM and a 
Pentium-class processor. The DSS Administration GUI requires more 
RAM than the previous interfaces. In our simplified test, the OS/2 Warp 
Server administration GUI used about 5 MB of RAM, and the DSS GUI 
used about 9 MB of RAM. Your measurements may, of course, vary 
considerably. 


2.3.2.2 Working with the Security Server 


The Security Server contains the database of user and group 
information known as the registry. This registry is loaded into memory 
when the server starts, so do not allow the server to swap excessively. 
Swapping will have a serious impact on performance. 


If you are using HPFS386, make sure that the allocation size for HPFS386 
cache does not cause swapping for other processes in the same 
machine. If necessary, reduce cache size or add physical memory. 


Adding Security Replicas in your environment will help improve logon 
performance and resource access for DSS Clients. This is especially 
true for DSS Clients which would have to access a Security Server 
across a WAN link. 


DSS Clients have credentials that expire and need to be renewed 
periodically at a Security Server. Lengthening the time before 
expiration will reduce the load at the Security Server. 


Allow DSS clients to use the cached credential information which 
resides on their systems. This means setting the confidence level to 
low. If the confidence is set to medium, the client must contact a 
Security Replica or master. If the confidence is high, the client must 
contact the Master Security Server. 
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2.3.2.3 Working with the Directory Server 


The Directory Server contains the information about all the resources in 
the cell in a database called the namespace. This CDS namespace is 
cached into memory at server start time. Do not allow the Directory 
Server to swap excessively: Otherwise, the Directory Server 
performance will be degraded. If HPFS386 is installed, check the 
HPFS386 cache size and adjust accordingly. 


In WAN environments, it is helpful to have a Directory Replica located at 
a remote site to improve resource access response time. The entire 
namespace does not need to reside at this replica. 


2.3.2.4 Working with Domain Controllers 


Legacy clients require the Domain Controller function for processing 
logons. If you have legacy clients (DOS/Windows, OS/2 V4 or Warp 
Connect, OS/2 Warp Server client, Windows 95 or NT), adding legacy or 
DSS Backup Domain Controllers will help spread the logon load and 
increase logon performance. OS/2 DSS Clients do not utilize Domain 
Controllers significantly during cell logon. 


DSS Domain Controllers are installed with a Security Replica by default 
and run the RGYSYNC service. If your legacy clients are at least at 
OS/2 LAN Server V4.0 and APAR IC13565, you can make more RAM and 
processing capacity available by stopping the RGYSYNC service. 


2.3.3 Logon Capacity 
As you continue the process of planning for and installing the Directory and 
Security Server for OS/2 Warp, a question arises regarding the number of 
servers needed for satisfactory performance of various activities in the cell. 


The External Performance Group at IBM Austin has developed a Java-based 
tool to assist you in estimating the logon capacity of typical server 
platforms. Their testing confirmed two key findings: 


1. 


File and print performance of the LAN Server product is essentially 
unaffected by its integration with the DSS Servers. 


. Logon performance is somewhat slower for a LAN Server (legacy) client 


logging on to a DSS Domain Controller as compared to that same client 
logging on to a LAN Server Domain Controller. 


The logon time for the DSS Client is longer than either scenario above. 
However, the developers found that much of the logon time is spent at the 
client. Therefore, DSS Servers can handle many concurrent DSS Client 
logons. 
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Based on their testing, the IBM developers found that if a DSS Server has 
sufficient memory (no excessive swapping), then the performance is 
dependent mostly on the processor speed. With this in mind, they 
developed a methodology to roughly estimate the logon capacity based on 
the server configuration, type of client load and the CPU type. 


The Logon Capacity Estimator is available to customers from the following 


URL: 


http: //www.software. ibm.com/is/sw-servers/directory/dssbks05.htm 


2.3.3.1 Working with the Logon Capacity Estimator 
The Logon Capacity Estimator requests the following input: 


* Configuration - The following predefined configuration options are 
selectable: 


1. 


Legacy 1- LAN Server (LS) logon processed by DSS Domain 
Controller and Security validation processed by DCE Server. 


. Legacy 2- LS logon plus one logon assignment processed by DSS 


Domain Controller (with Security Replica) and Security and Directory 
information processed by DCE Server. 


Legacy 3- Similar to Legacy 2, but the DSS Domain Controller is not 
running a Security Replica. 


. Legacy 4- LS logon processed by DSS Domain Controller which is 


also a Security Replica. 


. Legacy 5- LS logon processed by LAN Server Backup Domain 


Controller (no cell logon or validation occurs). 


. Legacy 6- Similar to Legacy 5 but adding one logon assignment. 


. Slim 1- DCE cell logon and security validation processed by DCE 


Server; DSS Domain Controller is running Security Replica. 


. Slim 2- Similar to Slim 1, but adding one logon assignment. 


. Slim 3- Similar to Slim 2, but DSS Domain Controller is not running 


Security Replica. 


- Processor Selection 


You must select the processor type for the DCE Server and the DSS 
Domain Controller. The processor types range from a Intel 80486-66 
MHz to a Pentium Pro 200 MHz with 256 KB L2 cache. 


From the input you provide, the Logon Capacity Estimator calculates the 
number of logons supported over a timespan of 15, 30, 45, and 60 
minutes. Figure 10 on page 54 shows an example of the Logon Capacity 
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Estimator with the Legacy 2 configuration and Pentium 133 MHz-based 
Servers. It estimates that 1041 logons of this type could occur in 30 
minutes, and the limiting system is the DSS Domain Controller. If this 
limiting system were to be replaced with a Pentium Pro 150 MHz system, 
the number of logons would increase to 1250, and the limiting system would 
now be the DCE Server. Note that increasing the DSS Domain Controller 
beyond Pentium Pro 150 MHz provides no additional logon capacity benefits 
in this scenario. Increasing the both the DCE Server and the DSS Domain 
Controller to Pentium Pro 200 MHz systems will now support 1980 logons in 
30 minutes, but the limiting server is still the DSS Domain Controller. 


As usual with capacity planning tools, the Logon Capacity Estimator is 


intended to be only an approximation of your actual results, which may vary 
from those provided by the tool. 
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Figure 10. Logon Capacity Estimator Example for Pentium 133 MHz Systems 





2.4 Other Preinstallation Considerations 


Note: We strongly recommend that you read the README.DOC and 
README.DCE in the root directory of the DSS CD-ROM for a list of known 
restrictions and considerations. We have mentioned a subset of the 
information here for your convenience. 


The following functions, which are available in OS/2 Warp Server, are not 
currently supported in DSS. Ensure that none of the listed items will impact 
your operation before you continue. You are required to remove or disable 
the unsupported functions. 
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Peer services are not supported on DSS Clients. 
The Local Security service is not supported on DSS Advanced Servers. 


The CHGSVR utility does not work on a server that has been migrated to 
DSS. 


Virtual Machine Boot (or specific DOS) sessions running DOS LAN 
Services are not supported. 


Macintosh Client Service is not supported on DSS Servers. This service 
is supported on existing OS/2 LAN Server and OS/2 Warp Server 
systems defined in a DSS resource domain. 


The NET ACCESS command is not supported for resources on DSS 
Servers. This function is provided through the DSS GUI, or may be 
carried using the dcecp -c acl command or the APPLY applet (see the 
online DSS Commands and Utilities for syntax and explanation). The NET 
ACCESS command is still valid for resources on legacy servers which 
have not been migrated to DSS. 


Remote IPL (RIPL) is not supported on DSS Servers or for DSS Clients. 
Existing LAN Server (LS 3.0, LS 4.0, Warp Connect, and Warp Server) 
RIPL clients and servers are supported in the DSS cell. However, new 
RIPL machines (or changes to existing machines) cannot be defined in 
the DSS cell after the LAN Server domain has been migrated to the DSS 
cell. Our recommendation is to leave a legacy domain with a server for 
the RIPL function. 


DSS supports no more than 11 characters for the name of a File and 
Print Server, due to a restriction on the length of the NetBIOS sockets 
name. During DSS installation, any server name longer than 11 
characters will be truncated to the first 11 characters. 


An alternate method of changing a long server name prior to DSS 
installation is to use the current level’s CHGSRVR utility to change the 
name of the server to one that is no more than 11 characters. 


Dynamic Host Configuration Protocol (DHCP) functionality is fully 
supported on DSS Clients. However, DSS Servers require a permanent 
TCP/IP hostname and address to ensure proper function in the cell. 


Chapter 2. Planning Your DSS Environment 55 


56 Inside DSS for OS/2 Warp 





Chapter 3. DSS Design Scenarios 


This chapter provides sample migration scenarios for companies that might 
be typical IBM customers. Most of them have distributed Local Area 
Networks (LANs) involving thousands of users. The migrations are dealt 
with in two stages. The first is the planning of the migration, and the second 
is the implementation method. We have included a new DSS installation (no 
existing OS/2 LAN Server) as well. Some of these examples include 
database sizing estimates based on several factors. Refer to Table 5 fora 
listing of size of the various DSS elements. 





Table 5. Approximate RAM Size of Database Entries 





Object Type RAM Size (KB) 


CDS Directory . 


CDS Object 
Alias (in CDS) 








Public Application (in CDS) 


User in Registry 





Host in Registry 1.0 








The process of adding a resource domain to your DSS cell creates five 
directories (the resource domain itself and four subdirectories, as shown 
in Figure 3 on page 17) and one object for each alias or public application. 
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-—— RAM and Disk Considerations 


Table 5 lists the memory requirements for items in the Registry and the 
CDS namespace. In DCE Version 1.1, a checkpoint file holds the 
contents of the CDS namespace. When the checkpoint file is loaded into 
memory, it increases to 2.9 times the size of the checkpoint file. This, of 
course, will increase the actual memory usage on directory servers 
beyond the estimated size of the CDS namespace using only the 
numbers above. 


As an estimate of the actual RAM requirement for the CDS namespace, 
multiply your calculated CDS namespace size (using Table 5) by 3. For 
example, if you calculate a 10 MB namespace, you will need 30 MB of 
RAM to hold the entire namespace. If there is not enough memory to 
hold the entire namespace, it will be swapped to disk. 


When the CDS server is updating the namespace on disk, the original 
checkpoint file is kept, along with the updated file. This means that the 
disk requirement for the CDS namespace is at least twice the size of the 
checkpoint file. 








3.1 Amalgamated Widget Company 
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The Amalgamated Widget Company has two sites located in cities 50 miles 
apart. The Home Office site contains separate LANs for the accounting, 
accounts payable, accounts receivable, order entry, and inventory-control 
departments, as well as additional LANs in the warehouse and shipping 
areas and Widget Finishing manufacturing area. There are 1,500 employees 
at this site. The accounts are fairly evenly distributed between the seven 
LANs. 


The Widget Stamping manufacturing area in the second city has 500 
employees and two LANs, one in the manufacturing area and one in 
shipping and receiving. The two sites are connected using a TCP/IP 
connection over a T1 (1.54 Mbps) line. 


Administration of the LANs at the manufacturing-only site is done by one 
person on a part-time basis. There is one full-time and one part-time 
administrator at the Home Office site. DSS is used to tie all of the LANs 
together for the purposes of consolidating administration and allowing some 
cross-domain resource access. 


The following is a diagram of Amalgamated Widget LAN structure prior to 
DSS migration. 
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Figure 11. Amalgamated Widget LAN Structure Prior to DSS Migration 


3.1.1 Migration Planning 
First, it is necessary to decide the cell structure. In Amalgamated Widget’s 
case, a single cell is sufficient. Using one cell allows the administrators at 
the Home Office to administer users, groups, and resources at both sites 
from a single location. In addition, DSS resource domains can be used to 
restrict resource access to only those employees who have a business need 
to access those resources. At the same time, the resource domains allow 
cross-domain and cross-site sharing of data and other resources for 
employees with a need to do so. 


3.1.1.1 DSS Core Components within the Cell 
The following components need to be defined within the cell: 


« Master Security Server 
- Initial Directory Server 
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* DSS Domain Controller 


In addition, we must also define Password Strength and Password 
Synchronization services (see 6.2, “Password Management Considerations” 
on page 168 for further information). We can also define optional Time 
Servers, Security Replica Servers, and Directory Replica Servers within the 
cell. The Security and Directory Replica Servers give protection against 
single points of failure and can also improve response times within the cell. 


3.1.1.2 Cell Design 

It seems logical to place the Master Security Server and Initial Directory 
Server within the Home Office site because this is where the majority of 
users and administrators are based. 


Sizing the Master Security and Initial Directory Servers: Each DCE Security 
account requires about 2 KB of RAM. As there are 2000 employees, 4 MB is 
sufficient. OS/2 itself needs about 16 MB, and to allow for expansion and 
systems management software, a 32 MB machine would be the bare 
minimum for the Amalgamated Widget Master Security Server. To allow for 
the security processes and overhead, a 48 MB RAM system would perform 
more satisfactorily. 


The resources needed for the Initial Directory Server can be calculated as 
follows: 


* Objects (Exported Programs, Aliases, Names, and Resource Definitions) 
require 2.2 KB (1.2 KB for the object and 1 KB for attributes) 


* Directories require 6.6 KB each 


Amalgamated Widget has about 2000 objects and 2000 directories. So to 
support the whole system from a single Directory Server they need: 


Objects (2000 * 2.2 KB) = 4,4 MB 
Directories (2000 * 6.6 KB) = 13.2 MB 
0S/2 = 16.0 MB 


Since the CDS namespace is about 18 MB, we multiply by 3 to reach a 54 
MB estimated CDS RAM requirement. Adding 16 MB for OS/2 brings us to 
70 MB of RAM. To allow for expansion and systems management software, 
an 80 MB machine is recommended. Today the cost difference for RAM is 
minimal. 


Replicas of the Security and Directory Servers: To gain processing speed 
and to ensure adequate availability during line failures, it is recommended 
that replicas be spread around the network. In Amalgamated Widget’s case, 
we recommended that a Security Replica Server be placed in the Home 
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Office site and a second in the Manufacturing site, separated by the WAN 
link. This will allow for clients to be authenticated by the Security Replica 
Server in case the WAN link is disrupted. 


Since the size of the Security Replica database is identical to the Master, 
the Security Replica systems should be on the same size machines as the 
Master Security Server. 


Directory Server Replicas are not necessarily identical copies of the Initial 
Directory Server. In each case, the root directory is copied to all replicas, 
but only subdirectories that are defined to the replica need be copied. The 
necessary size for the Directory Server replica may be calculated as 
follows: 


* Object Size = Number of Objects * 2.2 KB 
« Root Directory Size = Number of Objects in the Root * 2.2 KB 
¢ Subdirectory size = Number of Replicated Subdirectories * 6.6 KB 


Amalgamated Widget should have one Directory Replica Server in the Home 
Office site and another at the Manufacturing site. The number of objects 
defined to the root is approximately 200. Given that there are approximately 
2000 subdirectories and 2000 objects within the whole system and the 
geographic breakdown is similar to that of the employees, the replica size 
needs to be as follows: 


* Home Office replica size: 


Object Size = 2.2 KB * 1500 = 3.3 MB 
Root Directory Size = 2.2 KB * 200 = 0.4 MB 
Sub Directory Size = 6.6 KB * 1500 = 9.9 MB 
0S/2 = 16.0 MB 


Multiplying the namespace size (about 14 MB) by 3 gives us 42 MB. 
Adding OS/2 (16 MB) brings us to 58 MB. We round this up to 
recommend a 64 MB Server. 


¢ Manufacturing site replica size: 


Object Size = 2.2 KB * 500 = 1.1 MB 
Root Directory Size = 2.2 KB * 200 = 0.4 MB 
Sub Directory Size = 6.6 KB * 500 = 3.3 MB 
Total size = 5 MB + 16 MB (DSS + OS/2) = 21.0 MB 


Multiplying the namespace size (about 5 MB) by 3 gives us 15 MB. 
Adding OS/2 (16 MB) gives us 31 MB. Therefore, a 32 MB server should 
suffice, although a 48 MB Server would give plenty of space for 
application growth. 


Chapter 3. DSS Design Scenarios 61 


DSS Time Servers: l\t is generally recommended that at least three DSS 
Time Servers are defined for each LAN. In Amalgamated Widget’s case, 
there is no reason why this recommendation should not be followed. The 
overhead of running a DSS Time Server is low, so existing servers can be 
used for this function. One should be in the Manufacturing site and the 
other two in the Home Office site. 


3.1.2 Migration Build Order 
Migration to DSS for Amalgamated Widget is performed in the following 
order: 
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1. 


10. 


Pick a fairly low-utilized LAN in the Home Office site to act as the pilot 
for DSS implementation. 


. Build the Master Security and Initial Directory Servers. These builds are 


interdependent, so they should happen together. 


The next machine to build is the DSS Domain Controller on the LAN to 
which the Master Security and Initial Directory Servers are defined. 


. Client workstations that will act as administrator workstations should be 


migrated at this time. 


. This should be followed by a Time Server that can be on any of the 


servers on the LAN (providing they have sufficient RAM capacity). 


. The next action is to add the first Security Replica Server and Directory 


Replica Server. 


. A brief trial period should follow while the administrators familiarize 


themselves with the DSS environment and check that it is working 
properly. 


. Once the trial has proved successful, another LAN should be migrated, 


probably in the manufacturing site. DSS components for this should be: 


¢ DSS migrated Domain Controller 

¢ Replica Security Server 

* Replica Directory Server 

* Time Server 

« Administration clients (OS/2 platform) 


. Once the administrator is satisfied with the multi-site cell performance, 


other LANs can be migrated slowly. 


DSS Clients can be added as they are needed. It is recommended that a 
number of DSS Clients be defined in each site to allow for local 
administration. 
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We show the diagram of Amalgamated Widget after-migration cell structure 
in Figure 12 on page 63. 
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Figure 12. Amalgamated Widget Cell Structure after DSS Migration 





3.2 Dolly’s Large Bank 


Dolly’s Large Bank has three corporate offices, 15 regional offices, and 2000 
branch offices throughout the country. The branches range from 5 to 150 
people, with one or more LANs in each branch. 


There are dedicated administrators at the corporate and regional offices. 
Large branch offices have at least part-time administrators on site, and 
smaller branch offices are administered by the large branch administrators. 
In all, there are 20000 users with thousands of LAN Server domains. 
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Data-sharing and resource-sharing needs are varied and complex. Branch 
offices must share data with regional offices. Regional offices and claims 
offices must share data with the central site. The branch offices, regional 
offices, and central site are tied together with a variety of lines of varying 
speed and reliability. Both NetBIOS and TCP/IP are used. 


The following picture shows the Dolly’s Bank LAN structure prior to DSS 
migration. 
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Figure 13. Dolly's Bank LAN Structure Prior To DSS Migration 


3.2.1 Migration Planning 
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Dolly’s has decided to use a single DSS cell for their infrastructure. There 
are no architectural reasons why 20000 users cannot be placed into a single 
DSS cell, assuming that their hardware platform has sufficient capacity and 
the design is carefully planned. 


Deciding the DSS cell infrastructure requires a detailed analysis of the data 
and resource-sharing needs in the corporation. In this instance, it may be 
most practical to define hierarchical administrative resource domains 
containing regional offices and the branches they serve. DSS administrative 
resource domains can be used to restrict branch-office personnel to only 
those resources that they have a business need to access. At the same 
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time, it allows hierarchical administration of large branch offices and direct 
administration of smaller branch offices from the regional offices. Although 
each branch is currently an OS/2 LAN Server domain, some domains will be 
consolidated before DSS is installed in order to facilitate migration and 
subsequent administration. 


The central sites can be separate resource domains. Legacy clients can be 
used to access virtually any resource in the cell although the default will be 
to access the resources within their primary, or default, resource domain. 
Most branches access resources in other regions infrequently and can use 
existing LAN Server clients. 


3.2.1.1 Structure of Dolly’s Large Bank Cell 

Dolly’s Bank cell planners have decided to put the Master Security Server 
and Initial Directory Server in the London HQ location. Security Replica 
Servers will be placed in the other two headquarters locations and in the 15 
regional offices. Large branch offices (over 100 employees) may also have 
Security Replicas. The Directory Tree will be partitioned and replicated 
across the locations. Each Directory Replica at a location will be the 
read/write replica, and a read-only replica will also be held in that location. 
Time Servers will also be utilized to synchronize the time from the MVS 
mainframe in the headquarters location to all the DSS Servers. 
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For administrative ease, the cell hierarchy is defined as follows: 


HQ 


LONDON BRISTOL MANCHESTER 


REGION1 . . . REGIONS REGIONG. . . REGIONIO REGIONI1. . . REGION1S 


(branches) (branches) (branches) (branches} (branches) (branches} 
Figure 14. Dolly's Cell Hierarchy 


There are approximately 1500 users spread around the three headquarter 
resource domains: 750 in London, 400 in Manchester and 350 in Bristol. As 
previously stated, there are about 20000 employees in Dolly’s Large Bank. 
Today, there are approximately 4200 OS/2 LAN Server systems, or hosts, in 
place. Many of these servers will be migrated to DSS, mostly those in the 
HQ and regional offices and some in the larger branch locations. 


The sizing of the Initial Directory and Master Security Server systems can 
be calculated as follows: 


* Security and Replica Security Servers 


For a registry containing 20000 accounts and about 5000 servers, 45 MB 
of RAM is needed (20000 x 2 + 5000 x 1), which we round up to 64 MB. 
Adding 32 MB for OS/2 and other process RAM, we have a 96 MB RAM 
requirement. This system should be the fastest Intel-based system 
available, currently a 200 MHz Pentium Pro. 


¢ Initial Directory and Replica Directory Servers 


Each directory in the CDS namespace in DSS uses about 6.6 KB of RAM. 
Each object in CDS uses about 1.2 KB, and 1 KB for optional attributes. 
Each resource domain has four directories below it, and each alias and 
public application is an object. Each DSS Server appears twice in the 
namespace, as shown in Figure 3 on page 17. Dolly’s Large Bank 
estimates the following: 
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— 10000 aliases (CDS objects) 

— 1500 public applications (CDS objects) 

— 1500 resource domains (CDS directories x 5) 
— 4200 DSS Servers (CDS objects x 2) 


For about 7500 directories and 19900 objects, this requires about 94 MB 
of RAM (7500 x 6.6 KB + 19900 x 2.2 KB), which when multiplied by 3 
gives us 282 MB. However, unlike the Security Server, this structure 
can be spread across multiple systems, since the namespace can be 
partitioned. Therefore, the RAM requirement for each partition is less. 
Each HQ location and each region will have a CDS Master Replica and 
an Additional Directory Replica. The Master Replica is a read/write 
version of the resources that exist within that location. 


3.2.1.2 Resource Domain Structure for Dolly’s Branch Network 

Each of the 15 regions of Dolly’s Bank network is a resource domain. The 
relationships between branches within each region are quite complex in 
themselves. Some of the offices are sub-branches within main branches. 
Dolly’s has decided to provide three solutions for the branches. The 
solution for small branches is to provide connectivity to servers in the 
region for their resources. The medium branch has split resources between 
the region and the branch. Larger branches (over 100 employees) have their 
own local resources. The domain structure chosen is as follows: 
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Figure 15. Dolly's Resource Domain Hierarchy 


The diagram in Figure 15 shows the resource domain hierarchy chosen for 
one of the regions as an example. Defined to any particular region are 
small, medium and large branches connected by WAN links, usually at least 
64 KB. The small branches (less than 10 employees) do not have local 
servers, and they dial into a regional office for their resources with dialup 
routers, using the TCPBEUI protocol. As they grow, local resources can be 
added, making them a medium branch. 


The medium branches (up to 100 employees) have a LAN with local 
resources and servers. One local server, the OS/2 Warp Server Backup 
Domain Controller, also serves as the default logon server. There are 
legacy additional servers to provide resources locally. A DSS Primary 
Domain Controller is located at the corresponding regional office. Since 
branch user accounts and resources do not change often, there is not much 
Domain Controller Database (DCDB) or NET.ACC replication across the WAN 
links. As medium branches grow, DSS Servers can be added to their 
environment. 


The large branches (over 100 employees) have a setup similar to the 
medium branches, with the exception that there is a DSS Domain Controller 
and DSS Backup Domain Controller locally. In the event that the WAN link 


68 Inside DSS for OS/2 Warp 


to a region is down, the large branch can still function independently and 
continue to access local resources. 


3.2.2 Migration Rollout 
The rollout of DSS at Dolly’s Large Bank is divided into a pilot phase and a 
rollout phase. The pilot phase consists of three steps: 


1. Cell establishment at London HQ 
2. Pilot to regional office 
3. Pilot to three branch offices 
Once the three phases are complete, the other HQ locations can be 


migrated to the cell as well as to the regional offices and branch locations. 
Let’s discuss the steps for the HQ, regional office and branch pilot. 


3.2.2.1. Migration Sequence for the Headquarters Location 

The London HQ is selected to provide the test, and, eventually, the 
production environment for the initial installation of DSS. A test LAN is built 
and images of the production servers and data are used. Once the test 
servers are validated, they are updated with the latest data from the actual 
production servers, and they replace the legacy production server with a 
DSS-equivalent. 


The build order for London HQ is as follows: 


- Master Security and Initial Directory Server are built and the resource 
domain structure is created. 


¢ Domain Controller is migrated to DSS. 

* Time Server(s) are defined. 

¢ Administrators are upgraded to DSS Clients. 
3.2.2.2 Migration Sequence for the Regional Office 
Once the cell infrastructure is active in London, a smaller regional office is 
selected for the second phase, which is to ensure successful replication 


between the Master Servers at HQ and the replicas in this pilot regional 
office. The following steps are executed: 


¢ Security and Directory Replica Servers are defined. 
* Time Servers are defined. 


¢ Administrators are upgraded to DSS Clients. 


Chapter 3. DSS Design Scenarios 69 


3.2.2.3 Migration Sequence for Branch Offices 

The next phase involves selecting a small, medium and large branch to pilot 
connectivity to the regional servers. These steps differ between the three 
branch types. 


¢ Small branch—These locations require no changes at the branch since 
their servers are already at a regional office. The primary change is at 
the regional office, where the corresponding branch Domain Controller 
is migrated to DSS. Unchanged access to the server is the primary 
test-point to validate. 


« Medium branch—At the branch, there is no change to the clients or to 
the additional servers. A new Backup Domain Controller is placed at 
the branch with the resources of the original Domain Controller (DC). 
The original DC is migrated to DSS and moved to the regional office. 
Administration can be mostly from the regional office, freeing up the 
part time administrators to do more work directly related to the 
business. 


+ Large branch—Since the large branch was mostly self-sufficient and had 
local server resources, these servers are now migrated to DSS and kept 
in their existing locations. A Directory and Security Replica is placed on 
the DSS Domain Controller and can be moved to a dedicated system if 
the load is excessive. Administrators are migrated to DSS Clients, and 
the majority of users remain as legacy clients. 


Each step in the pilot phase allows the opportunity to fine-tune the design 
and balance resources based on capacity and availability. Once these 
issues are addressed, the second phase can begin, which was previously 
defined as the rollout phase. 
The rollout phase involves the following: 

* Migration of Bristol and Manchester HQ to DSS 

- Migration of remaining regions 

« Migration of remaining branches 


The process for the rollout phase is very similar to the sequence followed in 
the pilot phase. Again, any minor design enhancements discovered during 
the pilot phase can be executed here. 





3.3 Zelda Newan Incorporated 


Zelda Newan Incorporated is a very successful financial service company 
that recently merged with another firm to become the largest financial 
service provider in Parador. They have computerized their business 
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processes, but neither they nor their recent partner company have a defined 
LAN infrastructure. With their combined size, there are new data-sharing 
requirements and information-processing needs that cannot be satisfied with 
the existing systems. With the assistance of a computer consulting firm, 
they have decided to design, implement and integrate a LAN with their 
current environment to help meet these new requirements. The consulting 
firm is also working on writing a DCE-based application allowing transaction 
managers to have up-to-date information at their fingertips, called Project 
RETINA (REal Time INformation Availability). They will have the following 
environment, as shown in Figure 16. 


= MVS System 





Figure 16. Zelda Newan Main Sites in Parador 


In total, Zelda Newan has about 8000 employees. Their primary site, 
Northland, has an MVS mainframe running many applications related to 
client information management as well as government regulation databases. 
The sister sites, Weller and Gotthaus, have large RS/6000 systems for 
market analysis and forecasting. 


Since they do not currently have OS/2 Warp Server systems installed, there 
is no requirement for migration from these systems. All OS/2 Warp Server 
or DSS systems will be new additions to the computing infrastructure. 
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3.3.1 Cell Design 


Zelda Newan will have one cell spanning their entire network. Although 
they are geographically distributed, their design must allow for any of the 
three locations to continue operating independently in the event that their 
WAN connections are lost, as happens occasionally due to equatorial 
hurricanes. 


The Northland, Weller and Gotthaus locations will be peers within the cell 
structure. Each of these locations will have several DSS resource domains, 


which will be grouped under an overall resource domain for the location, as 
shown in Figure 17. 


root 


WELLER NORTHLAND GOTTHAUS 


Ct itt iti 


WL1 WL2 WL3 NO1 NO2 NOS GO1 O02 GO3 


Figure 17. Zelda Newan Cell and Resource Domain Hierarchy 
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3.3.1.1 Master Security Server 

The Zelda Newan cell designers, along with the consultants, have decided 
to place the Master Security Server on the MVS mainframe in the Northland 
location. This placement will allow them to synchronize the RACF IDs and 
passwords with the DCE IDs and passwords (for more information, consult 
OS/390 Security Services and RACF-DCE Interoperation, SG24-4704). The 
Weller location will have a read-only Security Replica on an RS/6000 AIX 
platform, as will Gotthaus. 


The resource domains in each location will be comprised of DSS Domain 
Controllers that will communicate with the corresponding RS/6000 Security 
Replica in that location. Having replicas in each location will allow DSS 
Clients to be authenticated by a local server, allowing for faster logons. In 
addition, if the WAN link goes down, local resources can still be accessed 
and utilized. 
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Since the DSS Domain Controllers install a Security Replica by default, it is 
helpful to determine the registry size. Zelda Newan is estimating about 
8000 users and about 3000 host systems. 


- 8000 users x 2 KB = 16 MB 
« 3000 hosts x 1 KB 3 MB 


The registry will be approximately 19 MB in size. Adding an additional 32 
MB of RAM for OS/2 and other server processes brings the total to 51 MB. 
We round up to 64 MB. Since the DSS Domain Controller may also provide 
file resources, we can add an additional amount for HPFS386 cache, 
depending on the number of resources shared. 


Although Zelda Newan will implement DSS Clients, they plan to install OS/2 
Warp Server clients and migrate them to DSS. So, before the last 
implementation phase is complete, legacy clients will perform logon 
requests to DSS Domain Controllers. The largest site, Northland, has about 
3500 users that will log on each morning over a 90-minute period. 

Assuming that the amount of RAM in the DSS Domain Controller is sufficient 
and the system will not swap excessively, we can use the Logon Capacity 
Estimator, described in 2.3.3.1, “Working with the Logon Capacity Estimator” 
on page 52 to see if their 200 MHz Pentium Pro can handle the load. Using 
the Legacy 4 scenario (LS logon processed by DSS DC, which is also a 
Security Replica) in the Logon Capacity Estimator, a 200 MHz Pentium Pro 
system is estimated to have capacity for 1782 logons in 30 minutes, which 
meets their requirements. 


3.3.1.2 Initial Directory Server 

The CDS namespace will be partitioned onto at least three different 
systems, one each in Northland, Weller and Gotthaus. Each location will 
contain the read/write replica for directories and resources local to that site. 
In addition, the cell planners want a read-only replica of the entire CDS tree 
to be placed in two locations, Northland and Weller. This will allow for 
better resource lookup performance as well as higher availability in the 
event of a failure of the read/write replica(s). All these CDS replicas will be 
implemented on RS/6000 AIX systems. In AIX DCE, each CDS directory 
needs 14.4 KB of RAM, and each CDS object needs 1.2 KB of RAM. 


Since the DSS Domain Controllers will also have a partial directory replica, 
the approximate size should be determined. The cell planners have 
estimated an average of 300 CDS directories and 3000 objects. This 
calculates to: 


¢ 300 directories x 6.6 KB = 2.0 MB 
* 3000 objects x 2.2 KB = 6.6 MB 
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3.3.2 
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The total is 8.6 MB, which we round up to 9 MB. Multiplying by 3 gives us 
27 MB of RAM. However, since Zelda Newan purchases memory in 16 MB 
increments, they will add 32 MB to the size of the DSS Domain Controller if 
the Directory Replica is installed. 


3.3.1.3 Distributed Time Servers 
Zelda Newan has decided on the following two requirements for system 
time in their environment: 


1. The MVS system clock will be used as the reference. 


2. All other systems must be synchronized to the MVS clock. 


The MVS system in Northland will have a Global Time Server (GTS) 
configured. It will also be configured as a nul/ time provider, which means 
that it uses its own clock as the time reference instead of an external 
source. Since the time inaccuracy factor will be very low, this time will have 
a high priority in time synchronization calculations. Using this method, it is 
critical that the MVS system programmers keep the MVS clock synchronized 
with a reliable source. 


With the MVS-based GTS system in place, Zelda Newan now needs a way 
for other Time Servers thoughout the cell to use the GTS in their time 
calculations. To do this, they will place a Global Courier Time Server in the 
Weller and Gotthaus locations. A Courier participates in the local time 
synchronization process, but it refers to a Global Server for its time instead 
of to its own clock. They will change the minservers attribute (see “How 
Time Services Works” on page 39 for a description of minservers) to 2 on 
these Global Couriers. This will force the Global Courier to contact two 
Global Servers, one of them being the MVS GTS. This will ensure that all 
three Global Servers are synchronized to the MVS time. 


To make sure that all other DCE (and DSS) Servers are also synchronized, 
each LAN will have one Local Time Server. Since minservers will also be 
changed to 2, the Local Time Server must contact a Global Time Server. 
Since the Global Servers are synchronized with the MVS time, all clients 
that obtain their time from a Local Time Server will also be synchronized 
with the MVS clock. 


Installation Considerations 


Since Zelda Newan is implementing a Master Security Server on a non-DSS 
platform, the considerations described in 6.2, “Password Management 
Considerations” on page 168 apply. The DSS Clients must have their 
password-strength server residing on a DSS system, so that the OS/2 LAN 
Server-like password syntax and rules can be applied. Otherwise, a 
DCE-only (not DSS-aware) password-strength server may allow a lower-case 
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password, which would not be valid for DSS Clients accessing resources on 
DSS Servers. 


It is possible for Zelda Newan to write their own password-strength server, 


which could run on any platform, and enforce password rules based on their 
specific criteria. 
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Chapter 4. Installation and Basic Configuration 


This chapter describes the installation and configuration of the Directory and 
Security Server for OS/2 Warp. Both the client and the server are covered 
as well as the various installation methods. 


Since there are many possible configurations for installation, this chapter 
will focus on a few specific and a number of generic examples. It is 
imperative that you plan your environment carefully before beginning 
installation, which might include a full cell design. A number of the options 
that you select cannot easily be changed later and may sometimes require 
a complete reinstallation. This can take some time, especially when 
components are on different machines. 





Important! 


The installation of the Directory and Security Server for OS/2 Warp 
replaces existing LAN Server ACLs with DSS based ACLs. As with any 
server migration, proper backup and disaster recovery planning should 
be done prior to beginning migration to ensure a successful recovery 
should an installation error occur. 





Several alternatives exist for proceeding with the migration. Among them 
are: 


¢ Perform a full backup of your domain controller as you would for 
disaster recovery. Proceed with the installation of DSS as you have 
planned. 


¢ Install the DSS Core Servers on machines that exist outside of your 
current domains. Once the cell is set up, the existing domains can be 
migrated into the cell as time permits. 


- Take this opportunity to test your disaster recovery process and skills. 
Put equipment intended for your DSS installation on an isolated network 
and restore an existing domain controller image to that machine. 
Perform the DSS installation. Replace the existing domain controller 
with its twin which has been migrated to DSS. 

The content of this chapter is as follows: 
¢- Preparing for installation 

¢ Installation order 


¢ Installation paths 
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* Sample attended installation of the core servers 
* Remote installation considerations 


* Importing users and resources 





4.1 Preparing for Installation 


If you have not done so, please review 2.1, “System Requirements” on 
page 25 for an overview of the hardware and software prerequisites before 
installing the Directory and Security Server for OS/2 Warp. 


Before you begin installation, you should ensure that the following is in 
place: 


* DSS requires OS/2 Warp FixPak 21 or higher be installed. FixPak 21 is 
shipped with the DSS product on a separate CD-ROM in most countries. 
You should obtain the most recent OS/2 V3 FixPak for your country. 
Many country-specific FixPaks can be obtained from: 


http://ps.software. ibm.com/ 


This applies to all DSS workstations and servers. It is not a requirement 
on legacy workstations or servers. 


Note: Fixpack 21 exhibits the peculiar behavior of not properly opening 
your LAN adapter when it reboots your system. A shutdown and reboot 
will correct this problem. The CD-ROM Fixpack installation routine 
starts the Service program in a background session. When it 
completes, do not press CTRL-ALT-DEL as instructed by the service 
program. Press CTRL-ESC and close the service program from the 
window list, and then perform a proper shutdown and reboot. 


« Request any current set of fixes for the Directory and Security Server for 
OS/2 Warp and OS/2 DCE from IBM Software Service. At the time of this 
publication, the current DSS FixPak is IP08550, and the current OS/2 DCE 
FixPak is IP08512. 


* Do not install DSS concurrently with any other product. 


- Do not install over LAN Distance or Remote LAN Access in OS/2 Warp 
Server. 


4.1.1 Pre-Installation Checklist 
Before you begin installation you should check the following items to 
increase the probability of a successful installation: 


1. Time and Time Zone 


Ensure that all the machines to be installed are within 5 minutes of each 
other. If this is not the case, your installation will fail. If all machines 
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are within a single time zone then you can use the TIME command from 
an OS/2 Command Prompt to set or view the current time setting. 


Also, ensure that the Time Zone variable is set in the CONFIG.SYS 
before installation begins. This can be done from the General tab in 
TCP/IP Configuration, or you can set the TZ variable directly by adding 
the following line to your CONFIG.SYS: 


SET TZ=SSSn 


We recommend that you implement the four-character 
assignment for time zone. 


sss The three-character label for your time zone. It must begin 
with a letter, must have 3 characters, and can contain 
spaces. The default time zone is Eastern Standard Time 
(EST). 


n The number of hours your time zone differs from Universal 
Timed Coordinated (UTC), formerly Greenwich Mean Time 
(GMT). If you are east of GMT you must put a minus (-) sign 
before the number. If you are west of GMT, you can 
optionally put a plus (+) sign before the number. The n 
values range from -12 to + 12. The default number of hours 
is five. 


For example, Austin, Texas, is in the Central Time Zone, so you would 
use CST6. Once Daylight Savings Time is invoked, you would use CDT5. 


If the TZ variable is not set prior to the installation of DSS, the 
installation process sets TZ to GMTO. 


. Drives 


When upgrading existing servers, DSS creates initial ACLs on each 
drive letter. If one of your drives is available but not accessible, the 
installation will issue a warning message. For example, a drive that is 
partitioned but not formatted, may later be formatted and added to the 
DSS Server with the ACLINIT command. 


. Communication 


During installation, components need to communicate with each other. 
Failure to communicate will cause a failure to install. A DSS Server 
must be able to PING itself and resolve its hostname in both directions. 
Let’s use the example of a server with a hostname of PONG and an IP 
address of 9.3.1.59. 
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Execute the following commands: 


[D:\]host pong 
pong.austin.ibm.com = 9.3.1.59 


[D:\]host 9.3.1.59 
9.3.1.59 = pong.austin.ibm.com 


If the DNS is running on the machine that you are about to upgrade, 
remember that this DNS may not be available for the upgrade. A local 
HOSTS file can be used for address resolution, and to ensure address 
resolution during install, it is recommended that you create a local 
HOSTS file and include the local hostname and address in the file. 


4. You may need to increase the number of OS/2 threads available in 
CONFIG.SYS for proper function of the DSS components. For a client, 
set THREADS=1024, and for a server, set THREADS=2048. 


5. If you are using NetView DM/2 to install DSS, you may see a SYS2070 
error message appear before the first reboot of the installation process. 
Obtain DSS APAR 1C15571 to resolve this problem with the INSTALL.EXE 
program. 





4.2 DSS Installation Order 
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An OS/2 DSS cell requires at least a Master Security Server, an Initial 
Directory Server and a DSS Domain Controller before any additional 
components can be installed. The order of installation of these core server 
components is listed below: 


1. Master Security Server 

2. Initial Directory Server 

3. DSS Domain Controller 
Some components require the services of other components before the 
installation/configuration process can be completed. It is therefore 
imperative that the installation order be maintained, especially if the server 


functions are spread across more than one machine. Additional components 
can only be installed once the above services are installed and available. 


If you migrate an existing OS/2 LAN Server or OS/2 Warp Server, to DSS, 
you can proceed to the following steps: 


1. Import the user, group and resource information using the DSSIMP 
command. 


2. Import the access control information for the server drives using the 
ACLIMP command. 
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These commands are described in 4.10, “Importing Users and Resources” 
on page 105. 





4.3 Installation Paths 
You can use one of two methods to install DSS: 
1. An attended installation using the Graphical User Interface 


To perform an attended installation, someone with an understanding of 
the component configuration needs to be present at the server or 
workstation being installed. 


Due to the complex nature of the product, we recommend that all core 
servers be installed via an attended installation using the Graphical 
User Interface (GUI). 


2. An unattended installation using the command line 


To perform an unattended installation, all of the installation and 
configuration information that would normally be keyed in can be coded 
into a file called a response file. The install can be initiated by anyone 
using the correct command line syntax together with the response file. 


Note: An account with cell administrator authority is required to install 
a DSS Server. This cell administrator user ID and password must be 
entered in the response file or on the command invocation for the 
unattended installation. This presents a potential security exposure 
which needs to be considered before unattended installation is used. 


To facilitate the installation on a large number of machines or where 
CD-ROM drives are not readily available on all machines, the command line 
installation would probably be most appropriate. 


For prototyping and testing, such as setting up key servers, an attended 
graphical installation would probably be most appropriate. 


4.4 Installing Core Servers 


It is important that the core servers install successfully before any other 
machines are added to the cell. Since there will usually only be a few core 
servers for any organization, we recommended that this installation be done 
in attended mode. The examples described in the sections that follow use 
the attended method of installation for the Core DSS Servers. 


Chapter 4 of the Up and Running manual lists a table describing the one, 
two and three machine core configurations and the general procedures that 


should be used to install them. 
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This section describes in more detail the installation of a one-machine and a 


three-machine core installation. 


recommended for production use. 


A three-machine core server installation is 





4.5 One-Machine Core Attended Installation 


The one-machine core configuration, which we recommend for testing 


purposes, is the simplest to install. 


In this configuration, the machine being installed must be an existing OS/2 
LAN Server Version 4 or OS/2 Warp Server Domain Controller. It will be 
upgraded to a DSS Domain Controller with the Master Security Server and 


Initial Directory Server functions also installed. 


4.5.1 Preparation Tasks 


The Domain Controller has the following software installed and currently 
configured with the parameters listed in Table 6. 


Installed Component 


File and Print Services 


TCP/IP 








Table 6. Domain Controller Current Configuration 


Relevant Parameters 
Domain Name 
Machine Role 
Server Name 

TCP/IP Address 
Hostname 

Subnet Mask 
Domain Name 


Name Server 





Value 

ITSC_DC1 

Domain Controller 
ITSODSS1 

9.3.1.25 

itsodss1 
255.255.255.0 
itsc.austin.iom.com 


9.3.1.74 


Before you begin installation you should check the steps listed in 4.1.1, 
“Pre-Installation Checklist” on page 78. In addition, you should do the 


following: 


- Start the server using the NET START SERVER command. 


- Log on as administrator. This will enable the DSS installation process 
to extract the ACL and other information needed from the Domain 


Controller. 


4.5.2 Installation 


To begin the installation, insert the DSS CD into your CD-ROM drive. If you 
are installing DSS onto an OS/2 Warp Server machine, select the Servers 
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folder from the Desktop. Then select the Server Installation icon within it 
and the DSS installation will begin. 





see 





Server 


Figure 18. OS/2 Warp Server Icon Contents 


You will be prompted for the language that you want to install, as shown in 
Figure 19. 


2 Confirm Server —- Language 





Figure 19. Language Selection 


If you are installing DSS onto a LAN Server 4.0 machine or you cannot 
locate the Servers icon, open an OS/2 Window and start the installation 
program by typing x:\INSTALL , where x is the drive letter of the CD-ROM 
drive. You will be presented with the first DSS installation panel. 
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_— Welcome to IBM Directory and Security Server for 03/2 


ue Warp (DSS) installation. 


Select the DS5 choice that best fits your environment. 


DSS for IBM LAN Services 


Integrate an 0S/? Warp Server (or an IBM LAN Server) 
network with Directory and Security Server. 


2 DSS for DCE applications 
Install BSS to use DCE applications such as DFS. 





Figure 20. Selection Panel 


You will be presented with the selection panel as shown in Figure 20. This 
panel allows you to choose between either DSS for DCE applications or DSS 
for IBM LAN Services. If you are migrating an existing OS/2 LAN Server or 
OS/2 Warp Server system, select DSS for IBM LAN Services. If you want to 
install DSS Servers other than File and Print (such as a standalone Security 
Server, Directory Server, Time Server, or replica), select DSS for DCE 
applications. In our scenario, the installation being done is on an existing 
Domain controller, so we choose DSS for IBM LAN Services. This will 
ensure that the LAN Server integration components are selectable. 
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[2 Setup and Installation 


Select the services to install. Select More to choose further 
details about that service. 


Current Status 


Current Yersion 


Current Yersion 


a ea Earlier YVersion 


Current Yersion 


- Current Version 


Not Installed 


@ TCPAIP Services.......... __ More... ie en | Current Version 
a Online Books 


Figure 21. Selection Panel - Components 





The selection panel shown in Figure 21 allows you to select which 
components of DSS you wish to install. Be aware that the Current Status 
description in your installation may differ from the one shown here. In this 
window: 


1. Select File and Print Sharing 


This option updates and installs the LAN Server and LAN Server 
integration components. The LAN Server integration components 
provides the function necessary for coexistence with legacy services as 
well as updates the LAN Server functions provided by DSS. 


2. Select Directory Services and click OK for the Initial Directory Server 


Each cell requires at least one Directory Server. The Directory Server 
contains a database of definitions for all of the resources and services in 
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the cell. When a client asks to use a resource or service, the Directory 
Server provides the address. 


3. Security Services is checked by default on the domain controller. Click 
on the More button and then select Master Security Server. Be careful, 
because the default is usually a Security Replica Server. 


There must be at least one Master Security Server in a cell. The 
Security Server performs security operations, such as authenticating 
users to ensure that they are who they say they are. There can be a 
number of servers holding copies of the security database. 


4. Select TCP/IP Services 


DSS ships TCP/IP Version 3.1, the same version included in OS/2 Warp 
Server. If you select TCP/IP Services, we recommend you check the 
More button and ensure that both connection-oriented and 
connectionless support is configured. 


5. Select the Next button to display the Configuration window. 


Hardware Resources Are Low 


This computer does not meet the 
recommended memory requirements. 


The recommended hardware resource 
levels are: 


Processor: 5x#6-90 Mhz 


Memory: 48 MB 
Hard disk space: 400 MB 


Installation can continue but 
performance may be compromised. 
Select Cancel to not install or select 


Enter to continue. 


@ 


PATE: i 





Figure 22. Warning Panel 


Should your hardware not meet the recommended requirements, you 
will see a warning panel as shown in Figure 22. 
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(-] DSS Server 


Select the type of File and Print Sharing Service resource 
e server You want to install. 

-— « Network Adapters 

L_y Autostart # Domain controller 


| # Directory and Secur Additional server 
— .f User ID and Passwe Backup domain controller 


A 


-— # Master Security Set 


4 





Type a name or accept the default names (if specified). 
— .¢ Protocol Options 


-— 4" TCP/IP Services | Server name 
t— ¥ Error Lagging Servic, ante 





fl 
L__. Adapters and Proto 8 
ad P A Resource Domain name 


Broadcast address 


itt lower ei sracertaners ince tance viene ate ett 


TTSC_DC1_ 


Parent Resource Domain 





Figure 23. Configuration Panel 


The configuration panel is shown in Figure 23. This panel is generated 

based on the components that you have selected in the previous panel. 

Each of the options that need to be configured are shown on the left. As 
you select an option, the configuration options are shown on the right. It 
is useful to move the right border of the left window pane to expose title 
words hidden by the window pane default size. 


Items with a red arrow require your review or more information for 
configuration. Click on each of the items and enter or verify the 
configuration information for each item on the right side. 


Table 7 (Page 1 of 3). DSS Configuration Details 


File and Print Sharing Same as in LAN Server Defaults taken 
Network Adapters Same as in LAN Server Defaults taken 
3886HPFS Same as in LAN Server Defaults taken 
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Table 7 (Page 2 of 3). DSS Configuration Details 





Component Description 


Parameters Supplied 





Autostart This section contains selections that will be familiar 
if you have installed OS/2 LAN Server and Warp 
Server. OS/2 DSS Server installation has added 
some selections which need to be carefully chosen 
for a successful installation. 


Audit Service to run. 


Directory Synchronization (DIRSYNC) keeps the 
Resource Domain’s domain control data base 
synchronized with the cell directory. This should 
usually be selected for installation on a Domain 
Controller. 


DSS Password Synchronization should only be 
installed on one Domain Controller in the cell. If 
this is your first Domain Controller, you must select 
it here and nowhere else. If the Master Security 
Server is also installed on the same machine, the 
DSS Password Synchronization will automatically be 
installed in the machine, so you should not install it 
anywhere else. If this Domain Controller is joining 
an existing cell whose Master Security Server is 
hosted on AIX or UNIX then the encryption protocol 
between the OS/2 DSS Server (DES or CDMF) and 


Password Synchronization service places the OS/2 
LAN Server logon information into the Extended 
Registry Attribute attached to the user account in the 
security registry. For more information, see 6.2, 
“Password Management Considerations” on 

page 168. 


Audit Service should be selected if you want the DSS 


the AIX or UNIX system must be the same. The DSS 


Defaults taken 





Directory and Security These parameters are used to configure the 
directory and security components of the server. 
The Hostname corresponds with the TCP/IP 
hostname given to this machine during TCP/IP 
configuration. 


The cell name is the name of the CELL that is being 
created. 





The LAN profile defines an alternate server that can 
be used to build a list of local servers. When a 
server is first initialized, it exports the binding to its 
entry in the Directory Services and adds its name 
entry to the LAN profile. Every server is 
automatically entered in the LAN profile for the 
related portion of the network. Local servers also 
import bindings from the LAN profile to build lists of 
servers with which they can synchronize. 
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DSS Hostname : 
ITSODSS1 


Cell name : 
ITSO_CELL1 


LAN-profile : lan-profile 
(default) 








Table 7 (Page 3 of 3). DSS Configuration Details 























Component Description Parameters Supplied 
User ID and Password This information is used to create your cell USERID for User ID 
administrator user ID and Password. It should be PASSWORD for 
kept secure. On subsequent installations this cell Password 
administrator user ID and password will be used to 
authenticate permission to add the server to the cell. 
Master Security Server Userid information mainly used for UNIX Defaults taken 
workstations 
Protocol Options Depending on your network and the choice of Selected only to use 
protocols you can select to use TCP/IP Socket TCP/IP Socket Access 
Access or NetBIOS Socket Access. Experience has 
shown that it is best to use one or the other and not 
both. This protocol is used to transport the DSS 
traffic only. The OS/2 LAN Server SMB traffic is 
carried on the protocol configured in the Adapters 
and Protocols section. 
TCP/IP Services Standard TCP/IP Configuration Defaults taken 
Error Logging Services Defaults taken 
Adapter and Protocol Select any additional protocols - MPTS configuration Defaults taken 
Services 








6. 
7. 
8. 


Select Next to continue. 
In the confirmation window select Install. 


When you are prompted, stop all unrelated applications and select 
Continue. 


The system automatically reboots after installation and starts the 
configuration process. As the existing definitions are copied, export files 
are created. We have included the following sample export files in 
Appendix B, “Sample Export Files” on page 193. 


ALDC1.EXP Aliases Export File 
APPDC1.EXP Public Applications Export File 
USRDC1.EXP User and Group Definitions Export File 


ITSO_DC1.EXP Domain Controller ACL Export File 
ADDDSS1.EXP Additional Server ACL Export File 
Select OK on the DSS Configuration is Complete window. 


The Shutdown is recommended window displays. It is highly 
recommended that you select shutdown on the desktop and reboot your 
machine. The installation is complete. You can now install DSS 
requesters or use legacy requesters to access the DSS Server. 
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Note: The DSS Tuning Assistant optimizes memory for the benefit of file 
caching on systems with HPFS386 installed. You should verify the size of 
the HPFS386 cache and change it accordingly based on the server 
requirements. For test purposes, you will not need as large a cache as 
you will during production, and giving some of the memory used in 
cache back to the system will give you a more responsive system. 





4.6 Three-Machine Core Attended Installation 


This installation is more complex than the other options because multiple 
systems are involved, but it offers the best availability, reliability and 
performance characteristics because all the components are on separate 
machines. 


Three-Machine Core Configuration 


Core Server 3 
Security Replica 
Domain Controller 
Time Server 







Core Server 1 
Master Security Server 
Time Server 














Additional Server Additional Server 
Backup Domain Controller client client Directory Replica 


Figure 24. Three-Machine Core Installation 


In Figure 24, three machines have been prepared to create the DSS cell. All 
of the machines have OS/2 Warp Server installed. The machines are 
configured as follows: 
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Table 8. Three-Machine Core Configuration Parameters 





Installed Relevant Machine 1 Machine 2 Machine 3 
Component Parameters 


File and Print Domain Name ITSODOM1 ITSODOM1 ITSODOM1 
Services 


Machine Role Additional Additional Domain 
Server Server Controller 
Server Name CHUYS CARRABAS OASIS 
TCP/IP TCP/IP Address 9.3.1.22 9.3.1.21 9.3.1.20 


Hostname chuys carrabas oasis 




















Subnet Mask 255.255.255.0 255.255.255.0 255.255.255.0 
Domain Name austin.iobm.com austin.iom.com austin.ibm.com 
Name Server 9.3.1.74 9.3.1.74 9.3.1.74 


4.6.1 Preparation Tasks 
The machines shown in Figure 24 on page 90 have software installed and 
configured with the following parameters as shown in Table 8. 


Before you begin installation you should review the steps listed in 4.1.1, 
“Pre-Installation Checklist” on page 78. In addition, execute the following: 


*- Start the server with the NET START SERVER command. 


« Log on as administrator. This will enable DSS to extract the ACLs and 
other information necessary during installation. 


4.6.2 Installation 
Follow these steps to install and configure the core DSS Servers across 
three machines. Prior to installation, machines may be configured as LAN 
Server Additional Servers or Domain Controllers, however one machine 
must be a Domain Controller and this machine is where the DSS Domain 
Controller will be installed. The DSS Domain Controller is installed last in 
the sequence. For our example in Table 8, Machines 1 and 2 are 
configured as OS/2 Warp Server Additional Servers, and Machine 3 is 
configured as the OS/2 Warp Server Domain Controller. 


Step 1 


1. Start at a Machine 1. Machine 1 will take on the DSS roles of Master 
Security Server and a Time Server. 
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2. 


10. 


11. 


12. 


13. 


14. 


15. 


Insert the DSS CD-ROM. Start LAN Server by typing NET START SRV . Log 
on as a domain administrator. Start the DSS installation program by 
typing x :\INSTALL , where x is the drive letter of the CD-ROM. 


. Select DSS for IBM LAN Services. 


On the Setup and Installation window, File and Print Sharing Services 
and Online Books are selected by default. 


. Select Security Services and click on the More... button to change the 


role from the default of Replica to Master Security Server. Select OK to 
dismiss the choice dialog for the Master Security Server. 


. Select Time Services and select OK for Local Time service. 
. Select TCP/IP Services if it is not already selected. 


. When you have chosen all the options you want to install, select Next to 


move to the Configuration window. 


On the Configuration window, items with a red arrow require your 
review or more information for configuration; other items have 
acceptable settings. Select each of the items on the left side of the 
window, and enter or verify the configuration information for each item 
on the right side of the window. 


Select File and Print Sharing and verify or change the displayed 
information. For your installed clients to use the same domain name, 
keep the same domain name on this panel. 


Select Autostart to verify that the proper services will be started on your 
server. If this is not a Domain Controller then Directory Synchronization 
will not be selected. Since this is the Master Security Server, you want 
to select DSS Password Synchronization. 


Select Directory and Security Services and enter a name for your cell. 
A cell hostname will be recommended for your machine. Do not use the 
name of any existing OS/2 LAN Server domain. 


Select Protocol Options. Choose a protocol for DSS services transport, 
either NetBIOS sockets or TCP/IP sockets, but we recommend that you 
not select both. 


Type in the new default User ID and Password values for the DSS cell 
administrator. We recommend that you use different values than the 
ones existing for your OS/2 LAN Server or OS/2 Warp Server. WRITE 
THESE VALUES DOWN! 


Select Initial Directory Server Address and fill in the information 
required to contact the machine that will be the CDS when it is installed 
for the transport selected in the Protocol Options choice (one choice 
should be grayed out). 
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16. 


17. 


18. 


19. 
20. 


21. 


22. 


Select Master Security Server. The default identification information for 
this machine is correct. 


Select Local Time Server. One Local Time Server will need to be 
configured as a Courier. You can select this system. 


Select TCP/IP Services and fill in, at least, the required TCP/IP address, 
subnet mask, and host name information. If TCP/IP is already installed 
on your machine, verify the displayed information. 


Select Adapters and Protocol Services and verify the information. 


When you have completed the configuration information, select Next. On 
the Confirm Installation window, select Install. When you are prompted, 
stop all unrelated applications and select Continue. 


Your system restarts automatically after installation files have been 
copied to your hard drive, and starts the configuration process. When 
you are prompted, go to the Initial Directory Server (Machine 2) and 
install and configure DSS there. 


Leave Machine 1 in the state it is in when it prompts you with the dialog 
to install the Initial Directory Server. You will need to return here to 
perform additional tasks. 


Step 2 


1. 


2 ND oO 


Machine 2 is to be installed next. Machine 2 will take on the DSS roles 
of Initial Directory Server and a Time Server. 


Insert the DSS CD-ROM. Start LAN Server by typing NET START SRV and 
log on as an administrator. Start the DSS installation program by typing 
x :\INSTALL, where x is the drive letter of the CD-ROM. 


Select DSS for IBM LAN Services. 


On the Setup and Installation window, File and Print Sharing Services 
and Online Books are selected by default. If you do not want this 
machine to be a File and Print Sharing Server, deselect the option for 
File and Print Sharing Services. 


Select Directory Services and select OK for the Initial Directory Server. 
Select Time Services and select OK for Local Time service. 
Select TCP/IP Services if it is not already selected. 


When you have chosen all the options you want to install, select Next. 
On the Configuration window, items with a red arrow require your 
review or more information for configuration; other items have 
acceptable settings. 
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10. 


11. 
12. 


13. 


14. 


15. 
16. 


17. 


18. 


. Select the options with a red arrow on the left side of the window and 


enter or verify the configuration information for each item on the right 
side of the window. 


Select File and Print Services and verify or change the displayed 
information. 


Select Directory and Security Services and enter a name for your cell. 


Enter default User ID and Password values for the DSS cell 
administrator. 


Select TCP/IP Services and fill in at least the required TCP/IP address, 
subnet mask, and host name information. If TCP/IP is already installed 
on your machine, verify the displayed information. 


Select Adapters and Protocol Services and verify the information. 
When you have completed the configuration information, select Next. 


On the Confirm Installation window, select Install. When you are 
prompted, stop all unrelated applications and select Continue. Your 
system restarts automatically after installation and begins the 
configuration process. 


When you are prompted, return to the Master Security Server (Machine 
1) and continue its configuration. 


Leave Machine 2 in the state it is in when it prompts you. You will need 
to return here to perform additional tasks. 


Step 3 


1. 


Return to the Master Security Server (Machine 1) and select OK on the 
window that instructed you to install and configure the Initial Directory 
Server. 


. Select Yes to confirm that the Initial Directory Server is configured. 


The machine will continue to perform a number of configuration tasks. 


. When you are prompted, go to Machine 3 to upgrade it to a DSS Domain 


Controller. 


Step 4 


1. 


No go to the machine that is your existing LAN Server Domain 
Controller. Machine 3 will assume the DSS roles of the cell Domain 
Controller, Security Replica, and Time Server. 


2. Start LAN Server by typing NET START SRV. Log on as an administrator. 


Start the DSS installation program by typing x:\INSTALL, where x is the 
drive letter of the CD-ROM. Select DSS for IBM LAN Services. 
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3. On the Setup and Installation window, accept the default options for File 
and Print Sharing Services and Online Books. Security Services is 
already selected and a Replica Security Service will be installed by 
default. This allows the Domain Controller to interoperate with LAN 
Servers and LAN Requesters that have not been migrated to DSS. 


4. Select Time Services and select OK for Local Time service. 


5. Select TCP/IP Services if it is not already installed. When you have 
chosen all the options you want to install, select Next. 


6. On the Configuration window, items with a red arrow require your 
review or more information for configuration; other items have 
acceptable settings. Select the options with a red arrow on the left side 
of the window, and enter or verify the configuration information for each 
item on the right side of the window. 


7. Select File and Print Sharing Services and verify the displayed 
information. 


8. Select Directory and Security Services and fill in the cell name. 


9. Enter default User ID and Password values for the DSS cell 
administrator. 


10. Select TCP/IP Services and fill in at least the required TCP/IP address, 
subnet mask, and host name information. If you already have TCP/IP 
installed on your machine, verify the displayed information. 


11. Select Adapters and Protocol Services and verify the information. 


12. When you have completed the configuration information, select Next. On 
the Confirm Installation window, select Install. When you are prompted, 
stop all unrelated applications and select Continue. 


13. Your system restarts automatically after installation and starts the 
configuration process. The DSS Configuration is Complete window 
displays, and prompts you to complete configuration of the Master 
Security Server and the Initial Directory Server. 


14. Leave Machine 3 in the state it is in when it prompts you. You will need 
to return here to perform additional tasks. 


Step 5 


1. Return to the Master Security Server (Machine 1) and select OK on the 
window that instructs you to install and configure the Domain Controller. 


2. Select Yes to confirm that the Domain Controller has been configured. 


3. The DSS Configuration is Complete window displays, and prompts you 
to complete configuration of the Initial Directory Server (Machine 2). 
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Step 6 


1. To complete Machine 2 configuration and bring up the cell, return to the 
Initial Directory Server (Machine 2) and select OK on the window that 
instructs you to complete configuration of the other Core Servers. 


2. Select Yes to confirm that the Domain Controller and Master Security 
Server have been configured. 


3. When the DSS Configuration is Complete window is displayed on all 
three machines, select OK on all of them. 


4. When the Shutdown Is Recommended window is displayed on all three 
machines, select OK. 


5. It is strongly recommended that you select Shutdown on the desktop; 
this creates backups of important files and updates the desktop icons. 


6. After shutdown is complete on all three machines, restart Machine 1 
first, Machine 2 second, and finally Machine 3 to establish the DSS cell. 


Step 7 
1. To import LAN Server data into the DSS Domain Controller: 


Note: Before you perform these steps, make sure you install any 
FixPaks available for DSS. In particular, you MUST apply APAR 
1C14166, available from IBM Service. This contains a new version 
of the ACLIMP migration import utility. 


2. On the Domain Controller (Machine 3), change to the drive where the 
DSS Installation program created the \DSSINST directory. This directory 
is a subdirectory of the root directory. Switch to the directory containing 
the DSS and ACL export files: cd \dssinst\acl 


3. Log on using the DSS cell administrator ID and password. Run the 
DSSIMP migration import utility: DSSIMP /ALL For more information on 
importing user and group information, refer to 4.10, “Importing Users 
and Resources” on page 105. 

4. Run the ACLIMP migration import utility: 


ACLIMP /f:ACL.EXP /h:USRGRP.HST /V 
Step 8 
1. To import LAN Server data into Machine 1: 


Note: If Machine 1 is NOT a File and Print Sharing Server, you can skip 
this section. If Machine 1 is a File and Print Sharing Server, you 
MUST apply APAR 1014166 before you perform the following 
steps. 
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2. Change to the drive where the DSS Installation program created the 


\DSSINST directory. This directory is a subdirectory of the root 
directory. Change to the \DSSINST\ACL directory. 


Copy the file \DSSINST\ACL\USRGRP.HST from Machine 3 to the 
\DSSINST\ACL directory on Machine 1. Log on using the DSS cell 
administrator ID and password. 

Run the ACLIMP migration import utility: 


ACLIMP /f:ACL.EXP /h:USRGRP.HST /V 


Step 9 


1. 


2. 


To import LAN Server data into Machine 2: 


Note: If Machine 2 is NOT a File and Print Sharing Server, you can skip 
this section. If Machine 2 is a File and Print Sharing Server, you 
MUST apply APAR 1C14166 before you perform the following 
steps. 


Change to the drive where the DSS Installation program created the 
\DSSINST directory. This directory is a subdirectory of the root 
directory. Change to the \DSSINST\ACL directory. Copy the file 
\DSSINST\ACL\usrgrp.hst from Machine 3 to the \DSSINST\ACL directory 
on Machine 2. Log on using the DSS cell administrator ID and password. 


Run the ACLIMP migration import utility: 
ACLIMP /f:ACL.EXP /h:USRGRP.HST /V 


The cell should now be fully operational. It is now possible to install 
workstations and other servers that are to be incorporated into the cell. 


4.7 Error and History Logs 


Errors encountered during the DSS Installation and Configuration program 
are recorded in ASCII files which are written to subdirectories on your hard 
disk. A record of the installation events for DSS and the system are written 
to history logs. 


An 


error log contains the following information: 

Name of the service or program that generated the error 
Date and time when the error occurred 

Reference number and text of the error message 


Description or cause of the error 


The following list provides the location and name of log files that are 
generated for DSS Client and Server installations. 
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DSSINSTLOGSDSSLOCAL. ERR 


The DSS installation error log 
DSSINSTLOGSDSSLOCAL . OUT 


The DSS installation history log 
OS2INSTALLDSSCFG.LOG 


The DSS configuration log 
OPTDCELOCALETCCFGDCE.LOG 


The DCE configuration log 


OPTDCELOCALVARSVCFATAL. LOG 


The DCE fatal error messages for DCE components (created by DCE 
Serviceability component (SVC)). 


OPTDCELOCALVARSVCERROR. LOG 


The DCE non-fatal error messages for DCE components 
DSSINSTRSPLOCALDSSCFG. CFG 


The configuration file that shows variables passed to the MKRSP.EXE 
command during installation. You can also set up a remote error log of 
your choosing on the code server by specifying the /L1 switch in the 
installation command statement. 


Most of the log files are held during installation or configuration. To view 
them type them on the screen. 


The DCEERMSG.INF is missing the hex error messages between 0x13282288 
11 error messages are present and represented by their 
These values are: 


and 0x14601001. 
decimal values. 


0x14129006 
0x14120997 
0x14129025 
0x14129098 
0x14129099 
0x141290A0 
0x141290B1 
0x141290B4 
0x141290B6 
0x141290BD 
0x141290BF 


(336760838) 
(336760839 
(336760869 
(336760984 
(336760985 
(336760992 
(336761009 
(336761012 
(336761014 
(336761021 
(336761023 


wee ws WS WS SS ~~ We 


KRB5KDC_ERR_C_PRINCIPAL_UNKNOWN 
KRB5KDC_ERR_S_PRINCIPAL_UNKNOWN 
KRB5KRB_AP_ERR_SKEW 

KRB5 REALM UNKNOWN 
KRB5_KDC_UNREACH 

KRB5 RC_I0 

KRB_KT_NOTFOUND 

KRB_KT_IOERR 

KRB5DES_BAD_KEYPAR 

KRB5_CC_10 

KRB5 FCC_NOFILE 


Also, the NOT_IN_IDL_SAMS page (heading xxxnewmsg), does not appear in 
the os2 dce source tree. 
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4.8 Remote Install Considerations 


The DSS components can be installed remotely. You can use one of the 
following mechanisms or software distribution tools to remotely install any 
of the components: 


¢ Redirected drive, such as SRVIFS or NFS 


¢ Software distribution tools, NetView Distribution Manager/2, or 
SystemView Software Distribution 


We will explain a redirected installation using the SRVIFS mechanism. 


The first method of installing DSS remotely requires having a remote drive 
that contains either the DSS CD or a copy of it. For performance purposes it 
is possible to copy the DSS CD onto the hard drive and then have the drive 
shared using any one of a number of redirection methods such as SRVIFS, 
LAN Server, NFS, or NetWare. 


The install program can then be started and the process continues just as it 
does with a local installation. For an unattended installation, a number of 
parameters are supplied to the command line install together with a 
response file. 





4.9 DSS Command Line Install 


4.9.1 


The command line install requires that the install command be issued at the 
workstation or server being installed together with a number of parameters. 
The syntax of the install command is as follows: 


Install Syntax 





>>—INSTALL—5 >< 
t/cid 


| 
-/cidredo | 











L-/AP: password 
[-/AV: password 
[-/R:Response_fi1e_name———| 
t-/G:path\di rectory -————__} 
t-/L1:path\Instal1_logfile_name 
[-/L2:path\Config_logfile_name—{ 
t-/P:password | 
[-/RK: keyword=value———t-— 
t-/S:path 
L/Tsd: J 

















Parameters 
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The following are parameters that can be used with the INSTALL command. 
If no parameters are specified, the installation program begins the GUI 
installation. 


/? Displays command help. 


/CID Command Line only, no user interface. This is only valid for CID 
installation. This indicates an unattended installation. 


/cidredo Reset CID reboot processing. This is only valid for CID 
installation. 


/AP:password 
Alias administrator password. 


/AV:password 
Alias administrator password verification. 


/R:Response_file_name 
Response file name. 


/G:pathdirectory 
Group response file. 


/L1:pathConfig_log_filename 
Installation log file name. If unspecified, the default is 
DSSINST.LOG. 


/L2:pathConfig_log_filename 
Configuration log file name. If unspecified, the default is 
DSSCFG.LOG. 


/P:password 
Cell administrator password. 


/V:ipassword 
Cell administrator password verification. 


/IRK:Keyword=value 
Response file Keyword override. 


/S:path Source Code Location. This is valid only for CID installations. 
[T:drive: Target Location. 
Note: 


* The parameter key may be preceded by a slash (/) or a dash (-). 
« The parameter value separator must be a colon (:). 
- All parameters are optional unless they are for CID only. 
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4.9.2 Response Files 
Response files need to be created before an unattended installation can 
begin. Sample response files are provided and located in the following 
directory on the DSS CD-ROM: 


D: CIDSAMPLES 


An index file called INDEX is also located within this directory. It lists each 
of the response files and for what configuration they have been created. 
You can modify these sample files for your configuration and then use them 
to install and configure your cell. 


We have included some of these sample response files in Appendix D, 
“Sample Response Files” on page 217. That section also includes a file, 
with detailed comments, that can be used to generate response files for a 
three machine core installation. 


Since installation and configuration can be performed in two separate steps, 
you can also split the response files into two files. To do this, move the 
installation keywords to another file and run the installation using the 
response file containing only the installation keywords. Then, return and 
run the installation with the response file containing the configuration 
keywords. 


Each section contains examples of response files for Install/Config and 
Unconfig/Uninstall. Full, Local, and Admin Config/Unconfig examples are 
also given where possible. The examples contain the minimum installation 
and configuration information required. If used, the response files can be 
modified to include other components and configuration information. At the 
top of each response file is the path and name of the sample response file 
which is located on the DSS CD-ROM in the CIDSAMPLES directory. Also 
listed is a sample installation command line statement which calls the 
installation program with that response file. 


The format of the response file is shown in the following sample: 


#asSsSSssSsassassssssssSssSssSsaSSa= 

# Sample Response File to show layout #<------------ See Note 1 
#esSssSssssassassasssssssSssSsaSaa= 

DSSTARGET = D: DCETARGET = E: <------------ See Note 2 


INSTALLSERVER = INSTALL 

INSTALLREPLICATOR = INSTALL 
INSTALLGENERICALERTER = INSTALL <- See Note 3 
deleteibmlan = Networks 

< netlb = > 

updateibmlan = Networks 
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< netl = *, *, *,120, 60, 12 > 

updateibmlan = Requester 

< Domain = DOMNAME > 

updateibmlan = Server 

< resourcedomain=resdom srvservices = LSSERVER > 


ConfigServerType = AdditionalServer <- See Note 4 
cell_name = example_cell 
cell_administrator = USERID 


master_security_server=(tcpip_name = security.example.com ) 
cds_server=( tcpip_name = directory.example.com ) 


host=( host_id=( tcpip_name=machine.example.com 
tcpip_addr=999 99.99.99 
netbios_host=MACHINE ) 

protocols=tcpip 

components= ( 
client=( config_state=configured <- See Note 5 ) ) ) 


Notes: 
1. Comments are preceded by the # character. 


2. The target location for the code is defined by the DSSTARGET and 
DCETARGET keywords. 


3. Each of the components to be installed needs to be listed. This is 
required for installation. For configuration-only response files, that is, if 
the code has already been installed, the installation keywords need not 
be specified. 


4. The LAN Server configuration keywords are used to define the manner 
in which LAN Server and the integration components are going to be 
configured. This does not affect the DCE component configuration 


5. The DCE components are configured here. These keywords are for 
configuration and each component together with the necessary 
configuration required is listed here. 


4.9.3 Installation Dependencies 
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The following are the component keywords for installation only. DSS 
requires that all currently installed components must be upgraded when 
installation is run if the components are downlevel. Installation will 
automatically specify any missing components that are required for the 
upgrade. 


The following is a list of components preceded by their dependent 
component. For example, InstallDFS requires that InstallIDCECLIENT be set 
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to INSTALL. Setting the InstallIDCECLIENT to install does not automatically 
infer that all of the dependent components will be set to install. In the case 
where, for example, InstallDCECLIENT is set to install and the Requester 
component is currently at a lower level it will be set to install. 


Instal 1DCECLIENT 
Instal1DFS 
Instal1AdminGUI 
Instal]Requester 
Instal1SECSERVER 
Instal1CDSSERVER 


Instal1Requester 
Instal 1Messenger 
Instal 1MsgPopup 
Instal1ClipBoard 
Instal 1DSSGUI 
Instal 1DSSSRV 
Instal]RemoteFaultTolerance 
Instal1FFST 
Instal]GenericAlerter 


Instal1DSSSRV 
HPFS386Drives 
Instal1DSSDC 
InstallAlerter 
Instal1BackRest 
Instal1NetRun 
Instal]lReplicator 
Instal1TimeSRC 
Instal1UPS 
Instal 1HPFS386 


Instal 1HPFS386 
Install FaultTolerance 


4.9.4 Configuration Dependencies 
The following is a list of the DCE configuration components and the 
components that require them to be configured. For example, the cds_cl 
requires that the sec_cl be configured: 


client (=sec_cl/cds_cl/dts_ cl) 
sec_svr 
sec_rep 
cds_svr 
cds_second 
gda_svr 
dts_client 
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dts_local 
dts_global 
dfs_client 

ems 

pw_sync_svr 
pw_strength_svr 


sec_cl 
cds_cl 


cds_cl 
sec_svr 
sec_rep 
cds_svr 
cds_second 
gda_svr 
dts_client 
dts_local 
dts_global 
dfs_client 
ems 
pw_sync_svr 
pw_strength_svr 


sec_svr 
sec_audit 


sec_rep 
sec_audit 


DSS Clients and Servers have DCE components as a prerequisite. The type 
of DSS configuration is determined by the type of code installed on the 
machine. If client code is installed and any requester component is 
specified for modification, then DSS Client configuration will be performed. 


For DSS Client configurations, one of the following combinations should be 
selected for DCE configuration: 


« slim_client 
* client 
* sec_cl and cds cl 


DSS Servers will be configured when the response file indicates a server 
type with the configservertype keyword and DSS File and Print code is 
installed on the machine. 
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DSS File and Print Servers require one of the following selections to be 
configured: 


* client 
* sec_cl and cds cl 


4.9.5 Remote Installation Additional Considerations 


The following should be taken into consideration when doing a remote 
install: 


1. Upgrade MPTS using the code supplied with DSS before starting the 
remote install. 


2. Ensure that you are logged on to any servers that are being installed so 
that the ACLs can be exported. If you do not include the ACLEXP and 
DSSEXP keywords in the response file, these functions must be performed 
manually before starting the installation program. 





4.10 Importing Users and Resources 


Once the migration of OS/2 LAN Server or OS/2 Warp Server to the 
Directory and Security Server for OS/2 Warp is complete, there are a few 
steps that need to be done. During the server installation process, you may 
have noticed that export files with server- and domain-specific information 
were created. It is the responsibility of the administrator or installer to 
manually execute the process of migrating the information from these export 
files into the appropriate DSS databases. 


Why doesn’t DSS do this automatically? There are a few reasons which 
make it more prudent for the administrator to manually import this 
information. For example, if the installation involves migrating several OS/2 
LAN Server domains where many users are defined in more than one 
domain, the administrator can decide which user definition will be imported 
into DSS. Also, if there are any resource definitions to be changed, this can 
be reflected in the export files so the importation process is successful. 


The importation process involves two steps, executed in the following order: 


1. Importing DSS resources, such as aliases and public application 
definitions, into the cell directory namespace, and importing user and 
group information into the cell registry. For this, we use the DSSIMP 
program. 


2. Importing access controls queried from the available OS/2 LAN Server 
drives as DSS was being installed. Since DSS has a modified access 
control structure, the ACL importation process will ensure that DSS 
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ACLs are now present on the server being migrated. For this, we use 
the ACLIMP program. 


There are two other migration utilities, DSSEXP and ACLEXP. These utilities 
are used by DSS to create the export files during the installation process. 
However, there are instances where the administrator may wish to run 
these utilities manually: 


¢ We install a new server and want to have the resources on the new 
system before migrating. 


* We want to migrate user and group information into the cell but do not 
want a separate domain controller. The corresponding server resources 
will not be migrated. 


More information on using DSSEXP and ACLEXP is available in the online 
DSS Commands and Utilities Guide. 


4.10.1 Domain Import Utility (DSSIMP) 
The Domain Import Utility, DSSIMP.EXE, takes the export files that were 
created by the DSSEXP.EXE program and migrates the information into the 
DSS environment. The following export file names are used: 


¢ ALIAS.EXP, which contains exported alias definitions. 
* PUBAPPS.EXP, which contains exported public application definitions. 
- USRGRP.EXP, which contains exported user and group information. 


Note: If you exported this domain information manually using the DSSEXP 
command, then make sure to specify any file names that you used 
during that process. 


In order to run DSSIMP, the following conditions must be met: 


1. The cell must be available. The Master Security Server and Initial 
Directory Server must be accessible. 


2. The DSSIMP command must be run from the Domain Controller which 
was just migrated to DSS. 


3. The cell administrator or equivalent must be logged on at this Domain 
Controller. 


The DSSIMP command has the following syntax: 
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| 
p>>—DSS IMP. t /ALL ; pd 


/ALIAS— | 
L=qliasfile | 
/APPS— —- 
L=qppsfile- | 
/USER- -— 
| 

| 

| 

| 

















L=yserfile— 





T 
| 
| 
| 
T T 
| |-/SKIP—— 
| [-/MERGE—4 
| /REPLACEH 
_/NOCONFIRM——————— 


You can use the following parameters with the DSSIMP utility: 


/ALL: 
Imports all information. 


/ALIAS 
Imports alias information. If the =aliasfile is specified, aliasfile is the 
file searched for alias information. If no aliasfile is specified, the 
default ALIAS.EXP file is used. 


/APPS 
Imports public applications. If the =appsfile is specified, appsfile is the 
file searched for alias information. If no appsfile is specified, the 
default PUBAPPS.EXP file is used. 


/USER 
Imports user and group information. If the =userfile is specified, 
userfile is the file searched for user and group information. If no 
userfile is specified, the default USRGRP.EXP file is used. 


/SKIP 
The global conflict resolution method is skip. This is the default for 
this parameter. 


/MERGE 
The global conflict resolution is merge. 


/REPLACE 
The global conflict resolution is replace. 


/NOCONFIRM 
Suppresses request for confirmation on command-line parameters or 
on overwrite of existing files. This option should be used when running 
in batch mode. 
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4.10.2 Conflict Resolution 
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We can migrate multiple existing OS/2 LAN Server Version 4 or OS/2 Warp 
Server domains into a single cell. There are no resource name conflicts 
when migrating aliases and public applications (domain resources) 
definitions to the cell since they are unique to the resource domain where 
they are defined. However, the migration of user and group definitions into 
the cell can result in name conflicts since we define users and groups at the 
cell level. These conflicts can occur with user or group names previously 
migrated or with those the administrator had defined manually. 


To resolve user or group name conflicts, the import utility provides three 
options. The default option is to use the SKIP parameter, but we can still 
specify any of the three options using the command line. The three options 
are: 


Method Description 


SKIP Does not import any definition of a user group that causes a 
name conflict. We use this option when we are not sure of 
the resolution method to use. It copies the user or group in 
error to a new export file of the same name, that contains 
only conflicts. The current file is backed up as 
inputfile.xxx, where xxx is a number from 001 to 999. We 
can edit the SKIP file to resolve conflicts by renaming or 
deleting names, or by specifying a conflict resolution 
parameter for individual reports (SKIP, REPLACE or 
MIGRATE). We then rerun the import utility repeatedly, until 
we resolve all the conflicts. 


REPLACE Deletes the current definition and adds the imported 
definition. We should use this option when the imported 
definition is valid and we no longer need the original 
definition. 


Note: 


1. This option deletes the current account for the user who 
is being replaced. It creates a new account for that user 
with the new attributes from the input file. All 
information associated with the deleted account is lost 
(ACLs, group memberships, account attributes, and so 
on). 

2. This option deletes all application selection lists, logon 
assignments, and private applications previously 
defined for the user in other resource domains. 

3. For a group replacement, the current membership is 
lost, and only users migrated after the replacement are 
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members of the new group. Any entries for the 
replaced group that exist on other DSS Servers are 
invalid and ACLs can not be created or deleted. 


MERGE Keeps the current definition but merges the imported 
information. For groups, it adds any users defined as 
members of a merged group to the existing group 
membership list. For users, it combines the new user 
definition with the existing definition. If there are any 
conflicts with logon assignments or applications, the 
existing information supplants the new information. 


There is also a field called collision resolution. \|t corresponds with each 
group and user record. We can use it for exceptions to the global settings. 
If the field is blank (as initially set by DSSEXP), it means that we use the 
global settings. If we specify a valid option within the conflict resolution 
field, that option overrides the global setting for that user. If we specify an 
invalid option, the resolution method uses SKIP as a default, and the error 
log file records the error. 


As previously described, the valid options for the conflict resolution field 
are: 


* MERGE 
* REPLACE 
* SKIP 


Group and user information are very closely related. If a group name is 
omitted or replaced and a user is defined as a member of that group later in 
the file, the importation of the user fails until we resolve the group 
membership. The user is imported without the group membership 
information. Groups and user-group membership are handled only after user 
conflicts are resolved. 


4.10.3 Access Control Import Utility (ACLIMP) 
The Access Control Import Utility, ACLIMP.EXE, takes the export files that 
were created by the ACLEXP.EXE program and migrates the information into 
the DSS environment. If access controls were exported as part of the DSS 
installation process, the following default export file name is used: 


¢ ACL.EXP, which contains exported access control definitions for that 
server. 


Note: If you exported access control information manually, make sure to 
specify the file names that you used during that process. 
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In order to run ACLIMP, the following conditions apply: 


1. The DSSIMP command must be run on the Domain Controller before 
ACLIMP can be run on any other server. 


2. For a given machine, use the ACL.EXP file that was created by ACLEXP 
program on that same machine. 


3. You should run ACLIMP on each DSS Server where you want the ACLs to 
be set. 


The ACLIMP command has the following syntax: 
>>—ACLIMP—/F: export_file— 





rT ie 
L/H:history_-filet “/yH 

We must use the following parameter with the ACLIMP utility: 

/f:export-file Name of the file created by ACLEXP that contains the 


exported OS/2 LAN Server Version 4 or OS/2 Warp 


Server ACL information to be read by ACL Import 
Utility. 


The optional parameters are: 


/h:history-file Contains a history of users and groups that were 
renamed or deleted during the importation of user 
and group information on the domain controller. This 
information is necessary if there are name conflicts 
resulting from the DSSIMP utility. The ACLIMP utility 
uses the information of how the name conflicts were 
resolved to correctly build the new ACL information. 


INV Verbose mode. We specify this parameter if we want 


to print the messages to the screen. 
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Chapter 5. Administrator Tasks 


The purpose of this chapter is to introduce OS/2 LAN Server or OS/2 Warp 
Server administrators to the administrative features available within DSS. 
This chapter describes the differences where applicable and highlights 
some of the new tasks that are required. 


It is recommended that you read Chapters 1 and 2 before continuing further 
with this chapter. Much of the terminology and many of the concepts used 
in this section are covered there. 


5.1 Overview 


Once you have successfully installed a Directory and Security Server for 
OS/2 Warp Server, the OS/2 LAN Server folder on your OS/2 desktop will be 
replaced with a LAN Services Directory and Security folder. 





LAN Services 
Directory and Security 


If you used the command line install and only installed DCE components, the 
DSS folder will not be present on your desktop. Instead you will have a DCE 
folder. This folder is also present after a DSS installation but is placed in 
the OS/2 System Setup folder. You can use the administration utilities in 
this folder to handle DCE administration. It is not recommended that you 
use these tools to administer DSS. 









/ ee ers Directory and Security Services DSS DSS UserAccount ERROR TAT LAN Server 
Lt 


Sree Administration Tuning Assistant AuditLag Utility 





2 Ee aS - Sa 
OD +i ae 20 ya 
4 LAN Server  Logoff Lagan MPTS Network Connections NetworkDDE Network Messaging 
Ei Error Log Utility Adaniers and Protoca! Senmicas and Clipboard 





Ml Start Directory and Security Server 


Figure 25. Directory and Security Services Folder Contents 


As shown in Figure 25, contained within the DSS folder are the following: 
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10. 


11. 


12. 


. Directory and Security Server Administration 


Allows you to administer DSS and Version 3.0 or later of OS/2 LAN 
Server. The interface is very similar to the OS/2 LAN Server 
Administration GUI object in OS/2 LAN Server Version 4.0. 


. Logon 


Allows you to log on to DSS cells and to OS/2 LAN Server domains. It 
also allows you to perform local logon for subsystems requiring local 
verification. DSS does not require local logon. 


. Logoff 


Allows you to log off DSS cells and OS/2 LAN Server domains. Ensure 
that all network applications are closed before logging off. 


. Audit Log Utility 


Allows users to view the File and Print Sharing Services audit logs of 
the DSS and legacy servers. 


. Error Log Utility 


Allows users to view the File and Print Sharing Services error log of the 
local workstation or a remote server. 


. Network Messaging 


Provides the interface for sending and receiving network messages. 


. Network DDE and Clipboard 


Provides the ability to cut and paste data into other applications using 
Dynamic Data Exchange (DDE) and clipboard functions. 


. Create 386 HPFS OS/2 Startup Diskette 


Creates startup diskettes for troubleshooting OS/2 systems with DSS 
installed. 


DSS User Account 
The current logged-on account. 
Network Connections 


Lists all connections made by the workstation or the logged-on account 
to shared devices. 


Start Directory and Security Client (or Server) 


Starts the Client Service on the workstation, also the Server if 
appropriate. 


MPTS Configuration 
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Allows you to configure PROTOCOL.INI file parameters for the protocols 
and NDIS drivers on the workstation. Refer to the online MPTS books in 
the User/Administrator Publications icon for information about using this 
MPTS interface. 


DSS Tuning Assistant 


Allows you to optimize the performance of DSS. 


There are also two text files, ERROR.TXT and README.DOC. ERROR.TXT 
contains a listing of the error codes for DSS, their descriptions and 
recommended actions. The README.DOC is a copy of the README.DOC 
located in the root directory of the DSS CD-ROM. 


General Hints on using the Administration GUI 


If frequently used, leave the Administration GUI open and running on the 
DSS administrator’s client machine, because loading the GUI can take a 
significant amount of time. Close the GUI at least once a week. This will 
release any resources that it has acquired but no longer needs. 


On occasion, an operation performed by the DSS Administration GUI 
may take a very long time to complete, preventing the use of other GUI 
functions. An example would be opening the Time Services folder in a 
Details View for a cell with many Time Clients and Servers. If you want 
to abort a long-running GUI operation you can log off DSS which will 
close the GUI. You may then log on again and re-open the 
Administration GUI. 


If the DSS Administration GUI has been up and running for some time, 
use the Refresh menu item to ensure that the most current information 
for the selected object is used. The Permission page, used to manage 
access, is dependent on the Registry folder being refreshed before 
newly created users and groups display on the page. 


If, on completion of installation, the DSS folder is not available or has 
been corrupted, you can run the CLNDESK.EXE program in the 
x:DSSINST directory which will recreate the folder. 


If the DSS Administration GUI fails to start or the icons appear 
scrambled, have default titles, or if previously saved information is no 
longer available, the NETGUI.INI file is damaged. This can be the result 
of a trap or abnormal end of the DSS Administration GUI. 


Replace the NETGUI.INI file from a backup copy. The file that stores 
persistent information for the GUI is the NETGUI.INI file. 


Use the following steps to replace this file: 


1. Close the DSS Administration GUI. 
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2. Copy x:\IBMLAN\NETPROG\NETGUI.BAK to x:\IBMLAN\NETPROG\NETGUI. INI, 
where x: is the drive where DSS is installed. 


To simplify invocation, the copy command can be put into a command 
file (for example, RESTGUI.CMD). 





5.2 Administration Types 


The role of the DSS administrator is considerably changed to that of a OS/2 
LAN Server Domain administrator. Administration tasks are split into two 
halves: 


¢ Administration of the cell and the DCE Servers within it 
« Administration of the resources in a resource domain. 


Cell administration consists of: 


« Managing DSS Security Servers and administering the cell registry 
maintained on the server. This includes administering user and group 
definitions in the cell. 


« Managing the DSS Directory Servers, the physical cell directory 
databases (clearinghouses) on these servers and the Cell Directory 
(namespace) defined within them. 


« Installing and configuring DSS Servers (Security, Directory, Time, and 
File and Print). The configuration of DSS Servers requires updates to be 
made to both the cell registry and directory databases. As a result, 
proper authority to these databases are required to install and configure 
the DSS Servers. The following groups are created when the DCE cell is 
first installed: 


acct-admin By default given controlling rights to the registry 
database 


subsys/dce/audit-admin By default given controlling rights to the audit 
service 


subsys/dce/cds-admin By default given controlling rights to the Cell 
Directory Server and clearinghouses 


subsys/dce/dts-admin By default given controlling rights to the Time 
Servers 


subsys/dce/sec-admin By default given controlling rights to the 
Security Servers 


The cell administrator is automatically a member of all these groups on 
installation. 


Resource domain administration includes the following: 
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¢« Administering directory, printer, and serial device resource definitions 
and public application definitions in the resource domain. 


« Administering DSS and OS/2 LAN Server File and Print Servers (Domain 
Controller, Backup Domain Controllers, Additional Servers) in the 
resource domain. 


Within DSS, authorization to administer any server or object is based on 
ACLs rather than privilege or operator rights, which do not exist, as such, in 
DSS. Authority and access permission to all operations and resources is 
granted or denied based on ACLs associated with the operation or resource. 
The cell administrator only has access to the whole cell on installation 
because he or she is a member of the above groups. There is nothing to 
stop, for example, the cell administrator subsequently being removed from 
the group subsys/dce/audit-admin, which would prevent him from tampering 
with audit logs. 


Resource domain administrators must be users that are created and 
explicitly associated to the resource domain. Once the account is 
associated, it can be given one or more of the following privileges: 


¢ Administrator 


Granting a user this privilege places him in the group 
realms/DOM1/ADMINS, where DOM1 is the name of the resource 
domain. This group is given full access rights to all resources in the 
resource domain when it is created. This account can therefore 
administer all aspects of the resource domain. For example, 
administrators can delete and change the settings of the resource 
domain. They also can create, delete, and change resource, server, and 
public application definitions in the resource domain. DSS resource 
domain administrators are not automatically granted authority to 
administer user and group definitions in the cell. They can, however, 
associate existing accounts with a resource domain. 


In order for the resource domain administrator to be able to create new 
groups and users, they would need to be added to the group 
acct-admins. 


¢ Server operator 


This account can administer directory, printer, and serial device 
resource definitions, server definitions, and public applications in the 
resource domain. 


¢ Print operator 
This account can administer printer resource definitions in the resource 


domain. 
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* COMM operator 


This account can administer serial device resource definitions in the 
resource domain. 


¢ User 


These accounts, by default, have no administrative authority in the 
resource domain, but can access resources defined to the resource 
domain if granted permission. 


Because of the DSS access control model, special resource domain groups 
are defined that represent the various privilege levels in the resource 
domain: 


- ADMINS 

* PRT_OP 

- SRV_OP 

- COMM_OP 
- USERS 


Accounts are added to the appropriate resource domain groups when they 
are granted resource domain privileges. They are removed from those 
groups when their privileges are revoked. These special resource domain 
groups display in the ACLs of all the objects associated with a resource 
domain, such as directory, printer and serial device resource definitions, 
server definitions, and public applications, and control access to these 
objects. 


Another difference between DSS resource domains and OS/2 LAN Server 
domains is that ACLs exist on the definition entry in the cell directory 
(resource, public application, and server definitions), as well as on the 
physical resource referenced by the definition. As part of the migration of a 
OS/2 LAN Server domain to a DSS resource domain, the ACLs for the 
definitions in the resource domain are automatically set up so that the 
resource domain administrators and operators have proper authority over 
the definitions they are allowed to administer. These ACLs should 
preferably not be changed. 


Also, as part of the installation and configuration of DSS Directory and 
Printer Resource Servers, ACLs are automatically set up on the server to 
allow resource domain administrators and operators the same level of 
authority over the server resources as that granted to administrators and 
operators on OS/2 LAN Servers. A resource domain administrator can 
change these defaults if desired. 


DSS Servers use a completely new authorization architecture to protect and 
control access to their resources. Administration of authorization in the 
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DSS environment differs from that of existing OS/2 LAN Server 
environments in three key areas: 


¢ Access Control Lists (ACL) exist on every object maintained on a DSS 
Server. 


¢ Access to resources is always determined by ACLs and never based 
solely on account privilege or operator rights. 


¢ Foreign accounts and groups (that is, users and groups defined ina 
different cell) can be specified in ACLs. 


5.2.1 Access Control Lists 
In the DSS authorization model, all resources have an ACL. This includes 
object definitions such as account, group, resource, and application 
definitions. DSS Servers do not support a sparse ACL model. For example, 
an ACL is created for every file and subdirectory when controlling DSS 
Server file resources. 


In the OS/2 LAN Server authorization model, ACLs are defined only on 
physical resources (that is, directories, printers, or serial devices). Object 
definitions such as account, group, server, and application definitions do not 
have ACLs associated with them. Existing OS/2 LAN Servers support a 
sparse ACL model in which ACLs need not be defined for each object. For 
example, ACLs are typically applied to directories or drives and not to 
individual files when controlling access to a server’s file resources. 


Note: In a resource domain which has both DSS and legacy servers, the 
administrator will be working with both these models. 


5.2.2 Foreign and Guest Accounts 
The DSS authorization model supports foreign account and group entries 
(that is, accounts or groups defined in a different cell to the server) in ACLs. 
Accounts and groups do not need to be explicitly defined in the same cell as 
the server. 


The OS/2 LAN Server authorization model does not support foreign account 
or group entries (accounts or groups defined in a different domain than the 
server) in ACLs. To be added to an ACL, accounts and groups must be 
explicitly defined in the same domain as the server. However, in OS/2 LAN 
Server, a GUEST user ID and GUESTS group are supported. Any user ID 
attempting to access a resource, but not found in the NET.ACC file, will be 
granted the permissions given to the GUEST ID. 


The GUEST ID is not supported in DSS, but permissions can be granted to 
otherusers (any authenticated user who does not appear in the ACL list) or 
unauthenticated (any unauthenticated user). 
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The GUEST account and GUESTS group are not migrated into the registry 
when migrating a OS/2 LAN Server to DSS. In order to allow GUEST 
account access on legacy servers in the DSS resource domain through the 
DSS Administration GUI, these definitions must be created in the cell 
registry and the GUEST group must be associated within the resource 
domain where the server is defined. 





5.3 DSS Administration Folder 


? Directory and Security Server Ad 








The DSS administration folder shown in Figure 26 contains two additional 
templates to allow for centralized administration. The Domain Template can 
be used to create a domain icon for legacy domains. In Figure 26, an 
additional domain has been added called PS_DOM. This enables the 
administrator to administer PS_DOM from the same administration GUI. 
Note that this does not integrate the domain into the DSS cell but rather 
provides for a single administration point. The domain icon also appears if 
the person logs on to a legacy domain outside of the cell. 
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Figure 26. DSS Administration Folder 
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When the domain is added to the GUI, the system checks to see if the 
Domain Controller can be contacted. The administration folder will not be 
created if the Domain Controller is not available. 


To ease administration, create an administrator ID within the legacy domain 
that is the same as the administrator ID within the cell. From this folder you 
can then administer both the DSS Cell as well as the legacy domains 
without having to log on and log off constantly, or use different machines for 
administration. Note that you would need to manually synchronize 
password between the cell and the domain if password expiration is 
operating in either. 


The Cell Template enables you to create additional cell definitions. This 
allows you to define a foreign cell as well as define trust relationships 
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between the cells. Refer to the online DCE Administrators Guide for more 
details on establishing trust between cells. 


The icon marked 
/.../itso_cell2 
is the folder that allows you to administer the cell we have created and all 


of the resource domains within this cell. The contents of this folder for 
itso_cell2 are shown in Figure 27. 
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Figure 27. Cell Administration Folder 


Initially the cell contains the following: 
« Registry 
- Resource Domains Folder 
¢ Distributing Computing Services Folder 
¢ A shadowed icon for the logged on user 
¢ A shadowed icon for each resource domain the logged on account is 
associated with. 


All of the above are managed here. We discuss each of them in the 
following sections. 





5.4 Managing the Registry 


The registry is a single database holding all the user and group definitions 
for the entire DSS cell. This is similar in function to the NET.ACC file which 
contained all the user definitions for OS/2 LAN Server but increases the 
scope of administration to larger distributed enterprise environments. 
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In order to provide this enterprise-wide administration, many of the functions 
originally performed within domains can now only be performed at the 
registry level. For example, user definitions have to be known throughout 
the cell so all user accounts have to be created within the registry. 


To perform operations on the registry, a user must be a member of the 
group acct-admins. The cell administrator is a member of this group by 
default. 
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Figure 28. Registry - Icon View 
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Figure 28 shows the contents of the Registry folder. Within this folder are 
two icons common to OS/2 LAN Server; accounts and groups. Previously 
these were contained within the OS/2 LAN Server domain administration 
GUI. These two folders contain the users or accounts and groups that exist 
within the cell. Users and groups are created and managed within these 
folders. 


The Policy Groups and Registry Schema folders are new to DSS. The policy 
groups folder contain policy definition groups. Users placed in these policy 
groups are governed by the policy rules defined within the policy group. For 
example, you could define a policy group called ‘permanent’ in which all the 
users have an account lifespan of forever, and a second policy group called 
‘temps’ where users accounts are only valid for 30 days. In OS/2 LAN 
Server only a single global policy could be defined using the NET ACCOUNTS 
command. 


The Registry Schema contains definitions for attributes that could be 
attached to any account within the cell. Once a schema entry is created it 
can be attached to any account. For example, an additional entry could be 
created to contain a user’s telephone number. This could be added to be 
part of the user’s profile. Thereafter the telephone number could be added 
as part of the users definition. 


The Registry Schema is used to store templates of Extended Registry 
Attributes in a single object. Extended Registry Attributes are used 
extensively by DSS to store user parameters which are particular to the 
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OS/2 LAN Server environment and which wouldn’t naturally appear in a DCE 
registry—for example, Is_home_dir stores the path to the user’s home 
directory and Is_script_path stores the user’s script path. Both of these 
parameters are stored in the NET.ACC file in the OS/2 LAN Server 
environment. In general, the administrator does not need to touch the icons 
in the Registry Schema folder. For more information about ERAs, refer to 
page 188. 


5.4.1 Creating and Managing Users 
In DSS, all users are defined within the registry. All users must be created 
in the Accounts folder in the registry when using the DSS GUI. To define 
users, you must belong to the group acct-admins. Users or accounts are 
created in exactly the same way as with OS/2 LAN Server or OS/2 Warp 
Server. An account is dragged off the template and dropped to begin the 
creation. This can also be done from the command line using the NET USER 
command. 
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Figure 29. Accounts Template 


The Accounts Template is shown in Figure 29. You will need to complete 
the pages in this template to create a new account. The fields within the 
pages are similar to the OS/2 LAN Server templates. 
The pages are: 

* Composition (new) 


This page displays the applications that are configured for the specified 
account or object. It cannot be changed. 


¢ Identity 


On this page, specify the identity information about the new account. 
This page is similar to the OS/2 LAN Server identity page. The account 
name can include any characters except (:) and the (@). 
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Only users with uppercase names less than or equal to twenty 
characters in length can log on and fully access all the functionality of 
DSS. This is consistent with that currently supported on existing OS/2 
LAN Server/OS/2 Warp Server Clients and Servers. 


Password 


The password information is used as it was with OS/2 LAN Server. 
There are, however, a number of changes allowing greater flexibility and 
security. There are two pages for the password section of the notebook. 
The first page is used to set and specify password information for the 
new account. 


The password valid checkbox specifies that the current password is 
valid. If this is unchecked, the next time a user logs on the password 
would have to be changed. The disable expiration, if checked, would 
specify that the account password would not expire. 


Note: Every user ID and password are also subject to a set of rules 
specified in the Policy Settings notebook page, either for the 
whole registry, or for a policy group to which the user belongs. 
Generally, the most restrictive rule will always apply. Checking 
the disable expiration is one case where the most restrictive rule 
does not apply, for instance, if the registry, or a policy group, 
specifies that the password does expire, it will be overruled by 
this setting. 


The password has to be typed in twice together with the password of the 
administrator that is creating this account. 


Only users with uppercase passwords that are less than or equal to 
fourteen characters in length can log on and fully access all the 
functionality of DSS. This is consistent with the logon conventions that 
currently supported on existing OS/2 LAN Server and OS/2 Warp Server 
Clients and Servers. 


Preauthentication has three possible levels for the user logon; None, 
Timestamp or Third party. Preauthentication is the process of a client 
obtaining a Ticket Granting Ticket (TGT), which it needs to present to the 
Privilege Server, in order to obtain a Privilege-Ticket Granting Ticket 
(PTGT), which it needs before it can access a resource on any DSS 
Server. 


When using the timestamps protocol, the client sends a timestamp 
encrypted with the principal’s (user’s) secret key and name. The 
security service decrypts the timestamp and checks that it is within five 
minutes of the correct time. Even more secure is the third party 
protocol. This requires that the client workstation is also defined in the 
registry, and has a master key known to the registry, which is also used 
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in the login process. For further details of DSS Security and the login 
process, please see A.5.1, “Authentication Service” on page 180 


Note: The “Maximum Invalid Atempts” field can be used to stop 
someone from continuously trying different passwords to access 
an account. If a user exceeds the maximum number, the account 
is disabled for the period specified in the Disable Logon Interval 
field. This parameter requires that either the timestamps or third 
party preauthentication protocols are being used. However, this 
parameter is only effective if the user’s login is actually being 
handled by the Master Security Replica. So, in many cases, 
checking this option will have no effect. 


The second password page is used to configure account password 
synchronization and password composition and strength checking for 
the account. These fields do not normally need to be changed. For 
further information on password synchronization, please see 6.2, 
“Password Management Considerations” on page 168. 


DSS 


The DSS section of the notebook consists of five pages and is used to 
set logon-related information for the accounts. 


The first page contains a field for a 48 character description about the 
account as well as the default resource domain that the account is to 
use. 


Note: Specifying a default resource domain for a user in this field does 
NOT automatically associate the user with this resource domain. The 
user must be associated with every resource domain where he requires 
access to resources on servers which have not been migrated to DSS. 
See 5.5.1.1, “Associating Users” on page 135 for further details. 


The second page defines whether a home directory is to be assigned for 
this account and the relevant information. This page is similar to the 
home directory tab with OS/2 LAN Server. 


The third page can be used to limit the account to specific workstations. 


On the fourth page logon assignments can be created for the specific 
account. These can be printers, serial devices or file sets. When 
specifying logon assignments, the list of available aliases displayed will 
be the list of aliases in the default resource domain of the logged on 
user. It is possible to specify logon assignments in other resource 
domains by specifying the resource domain name, for example, 
APPS@RESDOMA. 


The fifth page is used to define the public applications that will appear in 
the Network Applications folder of the account at logon time. 
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Account Info 


The fields here are especially useful since they enable you to further 
secure the system even if the account is in an uncompromised state. 
The “Account good since” and “Account valid” fields display the date 
that the account was last known to be valid. If a user suspects that his 
password is known by other persons, changing the password does not 
prevent the account from using tickets for accessing system components 
which were obtained, possibly fraudulently, before the password was 
changed. By changing these fields, all tickets obtained with the 
previous password are cancelled and only tickets issued using the new 
password are valid. 


Environment Info 


This page is used to define whether the account is a server or a client. 
Servers have accounts within the registry, and these accounts cannot be 
used to log on. Most of the options on this page are automatically 
assigned. 


The UNIX ID number is assigned for UNIX compatibility. You can select 
to have the number automatically generated or specify the number to be 
used. Normally, numbers between zero and 100 are reserved for 
system accounts. 


The home directory and login shell information is not used by OS/2, only 
by UNIX. 


Object creation quota refers to the number of registry objects that this 
account can create. 


The “Alias of” field can be used to define aliases. One account can be 
an alias of another account. Since each user id has a UNIX ID and a 
Universal Unique Identifier (UUID), the account name is really just a 
pointer to these. Aliases to an account can be defined by pointing to the 
same UNIX and UUID. 


Groups 


This page defines the group membership of the account much the same 
as it was in OS/2 LAN Server. 


On this page, you can also specify policy groups that the user may 
belong to. You can define additional policy groups that may impose 
additional restrictions on an account. Once the policy group is defined, 
the account can then be added to this policy group. 


Policy groups regulate such things as password length, format, and 
lifespan. 
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* Policy 


This page is used to set the ticket authentication policies for the new 
account. You can set the maximum number of hours for which an 
account retains the authority to acquire tickets to services (the number 
of hours the account retains a ticket-granting ticket). If this period is 
exceeded, the user must log on again before he or she is able to obtain 
access to resources. A ticket granting ticket allows an account to 
request and receive tickets (service tickets) to access other services 
(such as CDS) on the network. The second field on this page specifies 
the lifetime of the service ticket, once granted. When it expires, the 
process of obtaining a new service ticket is carried out automatically. 
Decreasing this value will increase the security of the system, but will 
result in an increase in network traffic. 


- Attributes 


This page is used to set the extended attributes associated with the 
Registry object as well as their values. You can define additional 
attributes to be associated with an account such as an Employee ID 
number by creating a new schema entry. This entry can then be 
selected here and a value attached to it. 


- Permissions 


This sets the permissions for other users on this object. Effectively, this 
specifies which users have the authority to make changes to this user 
account in the registry. By default the cell administrator ID and the 
acct-admin group have full access to this account. 


You can also perform a number of actions on existing users from the 
Context menu (click right mouse button on the user icon). These are some 
of the actions that can be performed from the User ID context menu: 


* Delete the user. 

* Change the configuration (applications associated with this user ID). 
- Add to a group. 

« Enable or disable the account. 

* Activate or deactivate the account. 

* Configure the password. 


5.4.1.1 Using the GUI with Many Defined Users 

It is likely that in a DSS environment, the User Accounts folder in the 
Administration GUI will contain a large number of users, especially if many 
OS/2 LAN Server domains have been migrated into the cell. 


When working with large numbers of users in the folder, it is possible, as 
with OS/2 LAN Server, to press a character on the keyboard to move to the 
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first user ID in the folder that starts with that character, or to search for an 
individual user ID using the Search option on the View pulldown menu. DSS 
introduces a Find option on this menu. By selecting the Find option, then B* 
for example, a new window is displayed that contains all user accounts 
beginning with the letter B. 


In a cell that contains many thousands of users, the User Accounts folder 
may become unwieldy. In this case it is possible to set up filters to limit the 
view of displayed users. To do this, open the Settings notebook for the User 
Accounts notebook. Select Filters. Now create a number of filters, (you 
could create one filter for each letter of the alphabet). 


For example, create a filter named A users with the following attributes: 


Attribute Account Name 
Comparison Type equal to 
Comparison Value A* 


When the User Accounts folder is opened with this filter selected, only users 
beginning with A will be displayed. Select settings from the View pull-down 
and change the filter to B Users and now all the users beginning with B will 
be displayed (selecting both of these filters will show all users beginning 
with A or B). By using filters in this way, it is possible to avoid having to 
open the folder with a view of all users in the registry, which could be tens 
of thousands of users. 


5.4.2 Creating Users from the Command Prompt 
The NET USER command can be used to list, create, modify, or remove 
users in the DSS cell. There are three new switches which have been 
introduced for the DSS environment: 


/CELL 
/RESDOM 
/DEFRESDOM 


The /PRIV and /AUTH parameters are no longer valid in DSS. All other NET 
USER parameters are the same as in OS/2 LAN Server. 


With DSS, it is not necessary to use the NET ADMIN command in order to 
direct the NET USER command to a server—use the /CELL parameter to 
specify the cell instead. 


The /RESDOM parameter is used when you wish to limit the extent of a list 
to a particular resource domain. 
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The /DEFRESDOM parameter is used to specify the default resource domain 
for a user. It is a required parameter. 


For example: 

NET USER /CELL:oclabcell 

Lists all the users in the cell oclabcell. 
NET USER /RESDOM:BRANCHA:oclabcell 


Lists all the users in cell oclabcell who are associated with the BRANCHA 
resource domain 

NET USER DAVEW PASSWORD /ADD /CELL:oclabcel] /DEFRESDOM: BRANCHA 

Adds a new user ID, DAVEW, with a password of PASSWORD, to the 


oclabcell, with a default resource domain of BRANCHA and also associates 
DAVEW with BRANCHA. If you follow this with the command: 


NET USER DAVEW /CELL:oclabcell /DEFRESDOM: BRANCHB 


Then the user DAVEW will now have his default resource domain changed to 
BRANCHB. He will now be associated with both BRANCHA and BRANCHB. 


5.4.3 Creating and Managing Groups 
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As for User Accounts, Groups are created in the registry and are cell-wide 
objects. In order to be able to create groups, a user must be a member of 
the group acct-admins. 
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Figure 30. Groups - Notebook 


The following items are different than OS/2 LAN Server when creating 
groups: 


¢« The group also has a UNIX ID associated with it. An Alias, however, 
cannot be defined for a group. 


¢ Additional attributes can also be associated with a group by using the 
attributes page. 


« By default, the cell administrator ID and the acct-admin group have full 
access to a group. To allow another permission to change anything in a 
group add that user on the permissions page and grant the user full 
access. 


- Users cannot be added when the group is created. To add a user toa 
group, you must drag and drop the user into the group folder or specify 
the group at the time the user account is created. 


Note: Alternatively, to add a user to a group, use the context menu on that 
group. From the Context menu, you can add or delete members from 
the group. 
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5.4.4 Managing Groups from the Command Prompt 


The NET GROUP command can be used to create new groups, and to add and 
delete users from a group from the command prompt. The use of the NET 
GROUP command is the same as in OS/2 LAN Server, with the addition ofthe 
/CELL and /RESDOM parameters. The /CELL parameter is used instead of the 
NET ADMIN command to update the registry from a workstation (use of the NET 
GROUP command without the /CELL parameter would update the local 
NET.ACC file on the workstation). 


For example: 

NET GROUP SUPPORT /ADD /CELL 

Creates the group SUPPORT in the registry. 
NET GROUP SUPPORT /ADD DAVEW /CELL 

Adds the user DAVEW to the group SUPPORT. 


The /RESDOM parameter is used to restrict the command to a particular 
resource domain. For example: 


NET GROUP /RESDOM: BRANCHA 


Lists all groups associated with BRANCHA resource domain. 


5.4.5 Managing Policy Groups 
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Policy groups do not exist in the OS/2 LAN Server security subsystem. They 
are similar to groups, but rather than a logical grouping of users or 
accounts, they define specific account and password policies such as 
password lifetime and format. Users placed into these policy groups are 
then subject to the policy rules defined by the policy group. 


Note: It is not advisable to associate a user with more than one policy 
group. Although an account can belong to more than one policy 
group, the policies for that account are regulated by only one policy 
group. As a result, this folder can contain accounts that are not 
regulated by this policy group. 


To change the permissions on the Policy Groups folder, open the settings of 
the policy group and set the permissions in the permissions page. 


To define a new policy group, open the folder and using the GUI drag an 
icon off the template and drop it. The notebook is shown in Figure 31 on 
page 131. 
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Figure 31. Policy Groups Notebook 
The following operations can be done from within the Policy Groups 
notebook: 
- Identifying a policy group 
* Specifying policies 
* Specifying attributes 
* Specifying permissions 


¢ Displaying effective policies 
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The accounts shown within the specific policy group folder are shadows of 
the accounts in the Accounts folder, which prevents you from managing all 
aspects of the account from here. 


To add an account to a policy group drag an account to the Policy Group 
folder or specify the policy group during user account creation. 


The following operations can be done from the Policy Group icon context 
menu: 

¢ Cloning a policy group 

* Deleting a policy group 


5.4.6 The Registry Schema 
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The Registry Schema is used to store templates of Extended Registry 
Attributes in a single object. The Registry Schema contains all of the 
registry schema entries and a template to create new registry schema 
entries. Once you have created a new registry schema entry you can attach 
this to an existing or new account. To perform this task, you must be 
logged on and meet the access requirements. 


To define a new schema entry open the folder and using the GUI drag an 
icon off the template and drop it. The notebook is shown in Figure 32 on 
page 133. 
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Figure 32. Schema Notebook 





5.5 Managing Resource Domains 


A resource domain is managed through the respective Resource Domain 
folder, contained within the Cell folder. The contents of the Resource 
Domain folder are shown in Figure 33 on page 134. The cell folder contains 
a shadow of each resource domain with which the logged-on user is 
associated, as well as a Resource Domain folder which contains all the 
resource domains in the cell. 
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Figure 33. Resource Domain Folder 


When a domain is migrated to DSS, the Domain Controller becomes a DSS 
Domain Controller and the domain becomes a resource domain. The DSS 
Domain Controller is a key server in the newly created resource domain. 


Resource domains are not required to have servers defined to them. You 
can create a resource domain solely for the purpose of creating an 
administrative hierarchy. In this case, neither servers nor other resources 
need to be defined. 


However, if a resource domain contains server definitions, one of these 
servers must be configured as a DSS Domain Controller. Among other 
responsibilities, the DSS Domain Controller makes resource domain 
resources accessible to OS/2 LAN Server (legacy) requesters and servers. 


To OS/2 LAN Server requesters and additional servers, the role of the 
Domain Controller appears unchanged. For this reason the Domain 
Controller synchronizes the NET.ACC and DCDB with the databases on the 
DSS Security and Directory Servers. 


Synchronization is done on a resource domain boundary. That is, for each 
resource domain, the administrator can decide whether that resource 
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domain should be synchronized. Each DSS Domain Controller synchronizes 
with a single resource domain. 


Directory and registry synchronization is no longer required when all of the 
OS/2 LAN Server requesters and servers in the resource domain have been 
upgraded to DSS Clients and Servers. 


5.5.1 Managing Resources in the Resource Domain 
The resource objects that are defined and administered within a resource 
domain are identical to those of OS/2 LAN Server domains. The following 
resource domain objects can be administered: 


¢ Directory resource definitions 

¢ Printer resource definitions 

- Serial device resource definitions 
¢ Public application definitions 


¢ Defined servers 


When an OS/2 LAN Server domain is migrated to DSS, the administrator of 
that domain becomes an administrator of the resource domain. It is likely, 
therefore, that this same person will continue to administer this set of 
resources. Administration of the resources in the DSS resource domain is 
very similar to that in the OS/2 LAN Server environment, involving the 
definition of resources and dragging and dropping them onto users or 
groups in order to define access control and logon assignments. Printer, 
Directory and Serial Device Resource Definitions each have their own 
folders within the resource domain folder. 


5.5.1.1 Associating Users 

Users can no longer be created at the domain level. All users exist at the 
cell level and are then associated with a particular resource domain. This 
association does not limit the user from accessing more than one resource 
domain. 


When the registry synchronization is carried out to the resource domain, 
only those users who are associated are synchronized to the NET.ACC file. 
A user must be associated with a resource domain before he can access a 
resource on a legacy server in that resource domain. He does NOT have to 
be associated with the resource domain in order to access a resource ona 
DSS Server. In theory, when all servers in a resource domain have been 
migrated to DSS, there is no longer any need to maintain a list of associated 
accounts; in practice, it is still advisable to do so for administrative 
convenience. 
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Note: When you create a user you need to specify a default resource 
domain. This does not, however, associate the user with that 
resource domain. 


Association of an account with the resource domain can be done by either a 
cell administrator or a resource domain administrator. Drag the user from 
the Registry Accounts folder into the resource domain Associated Accounts 
folder, or alternatively, select Associate an account from the Object 
pull-down menu in the Associated Accounts folder. 


When the user is associated with a resource domain the user type is 
required. This is shown in Figure 34. 
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Figure 34. User Privilege Level - Associated Accounts 
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The process that occurs after this point is that the user gets added to the 
related group. In the example in Figure 34, the user ITSO1 is selected to be 
an administrator, so the account ITSO1 becomes part of the group: 
realms/DOMAIN/ADMINS group. 


The user accounts can be managed from the Associated Accounts folder by 
clicking on them. However, in order to make any changes to the account 
which will require an update to the registry (for example, changing 
password or logon assignments), you must be a member of the group 
acct-admins. 
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It is also possible to perform a number of actions on a user from the Context 
menu. For example: 


« Delete the user. This deletes the user from that resource domain and 
not from the entire cell. 


¢ Change the configuration. This allows you to change the applications 
associated with this user ID. 


¢ Add to a group. 

¢ Enable or Disable the account. 

¢ Activate or Deactivate the account. 

¢ Configure the password. 
5.5.1.2 Associated Groups 
To associate a group with a resource domain, drag and drop the group from 
the Group folder to the Resource Domain Associated group folder. You will 


get a status message indicating that the process was successful. This is 
shown in Figure 35. 
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Figure 35. Group - Association 


Once a group is associated with a resource domain, you can delete the 
group (that is, remove it from the resource domain) or add a member from 
the Context menu (provided you are a member of acct-admins). The graphic 
in Figure 36 on page 138 shows the option for adding members to a group. 
You can select to add another group to this group as well. 
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Figure 36. Group - Adding Member 


5.5.1.3 Associating User and Groups from the Command Prompt 
The RESDOM command can be used to associate both users and groups with a 
resource domain. For example: 


RESDOM USER DAVEW /RESDOM:BRANCHA /ADD 
associates the user DAVEW with the BRANCHA resource domain. 
RESDOM GROUP SUPPORT /RESDOM:BRANCHA /ADD 


For full details on the RESDOM command, please see the \README.APT file on 
the DSS CD-ROM. 


5.5.2 Managing Access Controls 
The administrator is able to change access control permissions for 
resources in the resource domain in the same way as in a OS/2 LAN Server 
domain. When creating a resource definition, select Manage Access from 
the Context menu of an Alias icon, by dragging a User icon onto an Alias 
icon, or from the command prompt. 


When managing resources in a DSS resource domain, it is likely that an 
administrator will be working with resources on both DSS and legacy 
servers. Legacy servers still use OS/2 LAN Server ACLs. However, DSS 
Servers have a more sophisticated access control model. 
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For each file resource, there are three different ACLs: an Object (0) ACL, an 
Initial Container (ic) ACL and an Initial Object (io) ACL. 


oO The Object ACL applies to the directory itself. 


ic The Initial Container ACL will apply to any subdirectory (container) 
which is subsequently created within the directory (that is, not 
already in existence). 


io The Initial Object ACL will apply to any file (object) which is 
subsequently created in the directory. 

The permissions that apply to resources on DSS Servers are also different 

than those used on legacy servers. The DSS file resource permissions are: 

w write 


i insert (equivalent to OS/2 LAN Server Create) 


d delete 

c control (equivalent to both Attribute and Permissions in OS/2 LAN 
Server) 

t test (allows users to list what rights they have to an object) 

r read 

xX execute (can only apply to a file, not a directory) 


Typically, in an OS/2 LAN Server environment, ACLs are applied to 
directories only. When a user tries to access a particular file, then the ACL 
on the parent directory is used to decide whether the user has appropriate 
permissions. On a DSS Server, every file has an ACL associated with it. In 
order to change the ACL on any file or directory, the user must have control 
(c) rights to it. Every ACL must have at least one entry with (c) rights, or the 
ACL could never be changed for that file. 


5.5.2.1. Managing Access Control from the Command Prompt 

To manage access control on legacy servers in the resource domain, the 
NET ACCESS command can be used (together with the NET ADMIN command for 
remote access of a legacy server). However, neither of these commands 
works with a DSS Server. In order to manage ACLs on a DSS Server, an 
APPLY applet is provided (not to be confused with the APPLY command of 
OS/2 LAN Server which is used to propagate access control only). 


The DSS APPLY applet is a command line interface (CLI) that allows ACL 
changes to be applied to directory and file resources on DSS resource 
servers. You can issue an apply operation on a single directory or all of its 
subdirectories. The APPLY is successful only on directories and files on 


Chapter 5. Administrator Tasks 139 


140 


which you have ’c’ permission. The APPLY applet also allows you to view the 
ACL entries on a file or a directory. 


For example: 

APPLY C:\DATA 

shows all object ACL’s for the C:\DATA directory on the local server. 
APPLY C:\DATA /OBJ /I0 /IC 


Shows all object, initial object and initial container ACLs for the C:\DATA 
directory on the local server. 


APPLY \\SERVER1 C:\TEST /OBJ /IO /IC 


Shows all object, initial object and initial container ACLs for the C:\DATA 
directory on the server SERVER1. 


APPLY \\SERVER1 C:\TEST /ENTRYADD user:DAVEW:rwi /OBJ /10 


Adds to the object and initial object ACLs of the C:\TEST directory, 
permissions of rwi for user DAVEW. 


APPLY \\SERVER1 C:\TEST /ENTRYREP user:DAVEW:none /OBJ /I0 /IC /S 


Replaces any existing permissions for DAVEW in the object, initial object 
and initial container ACLs of the C:\DATA directory with none. Propagates 
these values to all files, subdirectories and files within subdirectories. 


Full details on the use of APPLY applet can be found in the README.APT file 
on the DSS CD. 


5.5.2.2 Using the Power of DSS Access Controls 

In an OS/2 LAN Server environment, the administrator has access to all files 
on all servers in the domain, ignoring any ACLs which correspond to those 
files. This is seen as a disadvantage by some companies using OS/2 LAN 
Server, who may wish to allow certain users to store highly confidential data 
on their servers without allowing access to administrators. In a DSS cell, 
however, access to all resources is always controlled by ACLs. This means 
that it is possible to configure ACLs so that even the cell administrator does 
not have any access to a particular resource (although keep in mind that at 
least one user must always retain (c)ontrol access to the resource). In 
practice, a sensible way to take advantage of this capability might be for the 
cell administrator to remove the resource domain administrator’s 
permissions from certain sensitive resources, granting full access to a 
particular user, but retaining sole (c)ontrol access himself. 


Don’t forget that on any legacy servers in the resource domain, these rules 
do not apply. The resource domain administrator will always be able to 
access all files on any legacy server regardless of any ACL entries. 
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5.5.3 Accessing Resources Across Multiple Resource Domains 
Any user in a DSS cell is capable of accessing a resource in any resource 
domain in the cell. However, the following considerations apply: 


¢ In order to access a resource on a legacy server in a resource domain, 
the user ID and password need to be in the NET.ACC of that legacy 
server. Therefore, the user needs to be associated with that resource 
domain. 


- A resource domain administrator can use the GUI to drag resources 
from other resource domains onto his associated users in order to grant 
access rights and set up logon assignments. However: 


— In order to be able to grant access rights to his users, he must have 
at least (c)ontrol rights to the resource in the other resource domain. 


— In order to be able to change logon assignments of his users, he 
must be a member of the group acct-admins. 


« A user may be granted logon assignments to resources across many 
different resource domains. If the user logs on to the cell at a DSS 
client, the user will be granted all those assignments. However, if the 
user logs on to a resource domain at a legacy client, the limitations of 
the OS/2 LAN Server APIs restrict the user to only those logon 
assignments within the resource domain to which the user is logging on. 
If you require users of legacy clients to gain access to resources in 
other resource domains, then you must set up cross-resource domain 
aliases (similar to OS/2 LAN Server cross-domain resources). This 
limitation does not apply to Home Directories. A user at a legacy client 
will always get access to his Home Directory, even if logging on ata 
different resource domain. 


5.5.4 Adding a Disk to a DSS Server 

In order for a cell administrator to be able manage access control on a file 
resource, an ACL giving (c)ontrol rights must already exist. If a new disk is 
added to an existing DSS Server, then an initial set of ACLs must be set on 
the drive. This is done using the ACLINIT utility. ACLINIT is run 
automatically as part of the migration process when an OS/2 LAN Server is 
upgraded to DSS. For full details on the ACLINIT command, please refer to 
the on-line DSS Command Reference. 


5.5.5 Logon Assignments for Mobile Users 
In large enterprises, it is becoming increasingly common for users to move 
frequently between different locations, still needing access to similar LAN 
resources. Of course, it is possible for a user to log on to the cell at any 
location, but it is likely that the user would not want to have all logon 
assignments pointing to the home location. More likely, the user would 
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want to load common applications and obtain printer assignments for the 
current working location, but still gain access to certain data areas and the 
Home Directory at his home location. In order to achieve this, it is possible 
to use logon scripts. 


If we consider the simple example of a company with a HEADOFF resource 
domain and three other resource domains, BRANCHA, BRANCHB and 
BRANCHG, all at remote locations. Each resource domain has common 
aliases set up, PRODAPPS and BUSAPPS as well as a number of printers 
and certain location-specific aliases. 


Now consider a user who is usually based at BRANCHA, but who regularly 
visits the other sites. A suitable script might be: 


NET USE J: PRODAPPS 

NET USE K: BUSAPPS 

NET USE LPT2: LASER1 

NET USE X: MYDATA /DOM:BRANCHA 


When this user logs on at a legacy client, whichever resource domain the 
user happens to be visiting, the user will gain access to the PRODAPPS and 
BUSAPPS resources on the local servers, the local printer, but will still have 
access across the LAN to his private data at the home site. 


This logon script could be placed in the PROFILE.CMD file. However, this 
would have to be done for each user on every server capable of handling 
the logon, which would be a very large administration task. Preferably, the 
setting up of system logon scripts could be used. The batch files 
BRANCHA.CMD, BRANCHB.CMD etc., should be placed in the path specified 
by the scripts parameter in the Netlogon section of IBMLAN.INI on each 
logon server. Then, for each mobile user, the NET USER command should be 
run to assign the correct script file. For example: 


NET USER DAVEW /SCRIPTPATH:BRANCHA. CMD 


5.5.6 Managing the Resource Domain Structure 
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Having migrated OS/2 LAN Server domains to DSS resource domains, it is 
possible to move them within the hierarchical structure of the cell, to merge 
them, or to move DSS Servers and their associated resources from one 
resource domain to another. 


The RESDOMMV command is used to move a resource domain. For example: 


RESDOMMV BRANCHB BRANCHA 


Moves the BRANCHB resource domain to become a child of the BRANCHA 
resource domain from wherever it previously sat in the hierarchy. The 
administrator of BRANCHA will now be able to define himself as an 
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administrator of all BRANCHB resources. (The administrator of BRANCHB 
will NOT be able to define himself as an administrator of BRANCHA 
resources). Note that any resource domains that are children of BRANCHB 
will also be moved. 


The SRVCHG utility allows an administrator to move a DSS Server from one 
resource domain to another. The utility must be run on the server that is 
being moved (of course, the server does not necessarily need to be 
physically moved for this operation to take place). This utility updates the 
resource domain parameter in IBMLAN.INI and changes any ACLs on the 
server which have entries for resource domain administrators or operators. 
For example: 


SRVCHG BRANCHA BRANCHB /MOVE 


Moves the server from BRANCHA to BRANCHB resource domain. Note that 
it is not possible to move a DSS Domain Controller to another resource 
domain without first changing the role of the server to member. 


The RESDOMDL utility is used by the administrator to delete an empty 
resource domain (after servers have been removed from it with the 
SRVCHG command). 


RESDOMDL BRANCHA 
deletes the BRANCHA resource domain. 


The RESDOMMG utility is used to merge two resource domains. It must be 
used in conjunction with the SRVCHG utility (to move the servers into the 
new resource domain) and the RESDOMDL utility (to delete the resulting 
empty resource domain). Note that when merging resource domains, it is 
possible that duplicate resource names will result. Any conflicts are written 
in a RESDOMMG.CON file, which needs to be edited by the administrator, 
who must decide whether each conflicting alias is to be renamed or deleted. 


Full details of all the resource domain management utilities may be found in 
the online DSS Command Reference. 


5.5.7 Administering the Domain Controller 
To support the unchanged OS/2 LAN Server requesters and servers, DSS 
Domain Controllers provide two new functions: 


1. Directory synchronization 


Directory synchronization ensures that changes to the DSS directory 
database are reflected in the Domain Control Database (DCDB). 
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2. Registry synchronization 


Registry synchronization ensures that all updates to the DSS registry 
database are propagated to the NET.ACC file on the Domain Controller. 


To reduce the traffic on the network, synchronization occurs on a resource 
domain boundary. A DSS Domain Controller is synchronized with a single 
resource domain, that is, changes to the cell registry database for accounts 
and groups that are associated with a resource domain are reflected in 
changes to the NET.ACC file on the DSS Domain Controller for that resource 
domain. Changes to the cell directory database for resources in that 
resource domain are propagated to the DCDB on that resource domain 
Domain Controller. 


Synchronization can be enabled or disabled for each resource domain in the 
cell, on an individual basis. It is enabled by default when the resource 
domain is created. 


Administrators can also start, stop, suspend, and resume synchronization 
from the command line and the DSS Administration GUI. Administrators can 
also set the interval between directory synchronization operations on a 
resource-domain basis. 


5.5.8 Directory Synchronization 
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DSS synchronizes the OS/2 LAN Server directory (DCDB) with the DSS 
Directory Server on the DSS Domain Controller (DC). The resource domain 
to which the Domain Controller belongs must be enabled for synchronization 
before the DIRSYNC service can synchronize information. 


The DIRSYNC service is included in the SRVSERVICES entry in the 
IBMLAN.INI file. Therefore, DIRSYNC is automatically started with the DSS 
DC Server startup. The DIRSYNC service runs at the interval, in minutes, 
defined in the IBMLAN.INI file. For example: 


[dirsync] interval = 5 

This interval can be changed to any value between 1 and 1440. The default 
is 5. 

The DIRSYNC service can also be administered through the Services folder 
in the DSS Administration GUI and also by entering: 

NET START DIRSYNC 

The parameter options for starting DIRSYNC are: 
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Parameter Definition 


/ INTERVAL: time Sets the number of minutes between checks for 
updated resources. The range is 1 to 1440. The 
default is 5. 

/FULLSYNC Initiates a full synchronization of all resource, server, 


and application definitions from the resource domain 
to the DCDB. Because FULLSYNC can consume 
significant system resources, especially if a large 
number of resource definitions exist, FULLSYNC 
should only be initiated when it is suspected that the 
DCDB is out of synchronization with the DSS directory. 


To suspend directory synchronization, enter: 
NET PAUSE DIRSYNC 


5.5.9 Registry Synchronization 
In addition to synchronizing NET.ACC, the DSS registry synchronization 
process is also a cell registry replica. That is, a DSS Domain Controller that 
has been configured for registry synchronization is also a DSS primary 
(Master) or secondary (Replica) Security Server. 


The DSS registry synchronization process is automatically started when the 
DSS Security Server is started, and if the sync_required parameter in the 
IBMLAN.INI file is set to yes. Stopping the Security Server stops the registry 
synchronization process. To disable registry synchronization temporarily, 
set the sync_required parameter to no. 


You can check on the status of the RGYSYNC process by examining the 
\IBMLAN\RGYSYNC\RGYWRKR.ERR error log file on the DSS Domain 
Controller running registry synchronization. Use an editor to view the file, 
or use the OS/2 TYPE command to list the contents of the file. The RGYSYNC 
process will remain active and synchronize updates as long as the 
RGYSYNC worker process, RGYWRKR.EXE, is running and the 
RGYWRKR.ERR file is either empty or if its last line contains the message: 
Registry update synchronized successfully. Use the PSTAT command to 
determine if RGYWRKR is running. 


Complete the following steps if you suspect that an error has occurred with 
the registry synchronization process. 


* On the DSS Domain Controller, log on to the DSS cell as an account that 
has administrative authority in the Domain Controller resource domain. 


« Invoke the RESYNCH utility from an OS/2 command prompt. This will 
synchronize the user, group and modals information from the registry to 
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the NET.ACC and DCDB. Note that in the command below, the s 
parameter is case-sensitive: 


[C:\]RESYNCH -s 


DSS Registry Re-synchronization Utility Version 1.00 
Copyright (C) IBM Corporation 1996 


Synchronizing registry information of resource domain OCLABA... 
The command completed successfully. 
The above process can only be completed from the command line and is not 


used for normal stopping and starting of the registry synchronization 
process. 


5.5.10 Managing Resource Domain Servers 
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When a Domain Controller is migrated to a DSS Domain Controller, the 
server’s definitions in that domain are initially added to the resource 
domain. 


The addition or deletion of OS/2 LAN Servers to a resource domain requires 
the DSS Administration GUI. Moving an existing OS/2 LAN Server from one 
resource domain to another requires deleting the server from its current 
resource domain and adding it to the new resource domain. 


Additions and deletions of servers after migration are handled differently. 


5.5.10.1 DSS Servers 

DSS Servers are added to a resource domain when they are installed and 
configured. They are deleted from a resource domain during 
unconfiguration. DSS Servers can be moved from one resource domain to 
another with the SRVCHG Utility. 


The roles of DSS resource servers MUST be changed through the DSS 
Configuration icon. Invoke the GUI, and select the new role of the server. 


5.5.10.2 Legacy Servers 

When an existing OS/2 LAN Server domain is migrated into the DSS cell, the 
existing OS/2 LAN Servers (LS 3.0, LS 4.0, and OS/2 Warp Servers) are 
added to DSS resource domains as part of the migration. Newly installed 
DSS Servers are added to resource domains during installation. 


To add existing OS/2 LAN Server or OS/2 Warp Servers to DSS resource 
domains after migration, the following steps must be taken from any DSS 
Client or Server: 
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1. Create an account in the DSS cell for the existing OS/2 LAN Server: 
NET USER <LS server name> <LS server password> /DEFRESDOM:<resdomname> /ADD 


2. Remove password synchronization and strength attributes from the 
account: 


dcecp -c princ modify <LS Server Name> -remove {{pwd_val_type 1} 
{password strength} {pwd_mgmt_binding} {foreign _registry}} 


3. Add the OS/2 LAN Server to the resource domain: 
RESDOM SERVER <LS server name> /RESDOM:<resdom name> /ADD 
On the OS/2 LAN Server: 


a. Edit the IBMLAN.INI file and change the DOMAIN entry to the 
broadcast address of the resource domain where the server is being 
added. 


Note: To determine the broadcast address of the resource domain, 
the following command can be issued from a DSS Client or 
Server: 


RESDOM DOMAIN <resdom name> 


Save and exit the IBMLAN.INI file. The remaining commands in 
uppercase should be typed at the command prompt. 


b. Type NET STOP NETLOGON 
c. Type NET ACCOUNTS /ROLE: STANDALONE 


d. Logon to server with an ID that has administrative authority on the 
server (for example, LOGON USERID /P:PASSWORD /V:L). 


e. Type NET USER <LS server name> /DEL 


—h 


. Type NET USER <LS server name> <LS server password> /ADD 


The LS server password must be the same as the one specified in 
step #1, which was issued from any DSS Client or Server. 


g. Type NET GROUP SERVERS <LS server name> /ADD 
h. Type LOGOFF /D 

i. Type NET ACCOUNTS /ROLE:MEMBER 

j. Type NET STOP REQ 

k. Type NET START SERVER 
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5.6 Distributed Computing Services 
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The Distributing Computing Services are administered through the 
Distributing Computing Services folder shown in Figure 37. 
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Figure 37. Distributed Computing Services Folder 
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Before describing the administration of DSS Servers, it is necessary to 
understand how the DSS Servers are related and why it is important to 
perform the administrative tasks associated with them. 


The Directory Servers use the Security Server authentication service to 
prove to each other that they are valid servers rather than imposters 
attempting to mine information from the directory database. They use the 
Access Control List (ACL) facility to restrict Directory Server administration 
to only those accounts that have been granted access. Entries in the 
Directory Server database are time-stamped, using the facilities provided by 
the Time Server. 


The DSS Domain Controller uses the Directory Server to locate objects, both 
in the local cell and in remote cells. It also stores the DSS resource domain 
information in the Directory and Security Server database. The DSS Domain 
Controller also uses the Directory and Security Servers to obtain resource 
information for propagation to unchanged additional servers via the 
NET.ACC and DCDB files. The DSS Domain Controller uses the Security 
Server to authenticate unchanged OS/2 LAN Server Clients and Servers. 


The Time Server registers itself as an object in the Directory database and 
uses the Directory Server to find other Time Servers in the network. It uses 
the Security service to ensure that it is communicating with valid Time 
Servers, rather than imposters. 


The Security Server registers itself with the Directory Server as an object in 
the Directory database. Security services uses the time synchronized by the 
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Time Servers to ensure that passwords and the service tickets that allow 
clients to use DSS services are properly time-stamped and voided when 
they expire. 


5.6.1 Directory Service 
The Directory Server, also called the Cell Directory Service (CDS), is used 
by the DSS services to locate objects in the network. It stores information 
about objects, such as resource domain servers and resource definitions in 
a database that represents a cell namespace. The cell-wide directory 
service frees users from knowing the real location of these resources. For 
example, clients can access directory and printer resources in their local 
resource domain or any other resource domain in the cell without knowing 
or caring about the real physical location of the resource. 


The database in which the namespace is stored is called a clearinghouse. 
Clearinghouses contain replicas which are physical copies of the database 
or of portions of the database. One feature of DSS is that the directory 
database can be replicated on several Directory Servers throughout the 
network. This facility allows remote sites, such as branch offices, to 
maintain a local copy of the directory to improve performance and to ensure 
that the directory is available even when the communication line to the 
Master Directory Server is down. 


All of the above tasks can be performed through the GUI shown in 
Figure 38. 
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Figure 38. Directory Services 


The GUI shows the CDS schema as well as the Directory Server or replicas 
that may be present. In our example, there is only one Directory Server: 


hosts/ITSODSS2/cds-server 


From the context menu, you can: 


- Start the server 
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¢ Restart the server 
* Stop the server 


*- Get the current status of the server 
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Figure 39. Directory Services Notebook 


Figure 39 shows the settings notebook of the Directory Server. From here 


you can: 
¢ Check the start options for the server 


¢- Check the statistics of the server 
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* Change the permissions to add additional administrators to administer 
this server 


If you have any CDS clerks, Global Directory Agents or CDS replicas in the 
cell, regardless of their location, they can be managed from here. 


5.6.2 Security Service 
The main role of the Security Server is to allow DSS Clients and Servers to 
prove their identity. Within a single cell there will only be one Master 
Security Server but there may be many replica Security Servers. In 
Figure 40 there are two Security Servers. ITSODSS5 is the Master Security 
Server and ITSODSS3 is the Domain Controller which is a Replica Security 
Server. 
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Figure 40. Security Services 


The Context menu on the replica Security Server allows you to start, restart, 
stop, get the status or synchronize the server. Selecting Synchronize the 
server will synchronize it with the Security Server, obtaining the most recent 
contents of the registry. 


The Context menu on the Master Security Server allows you to start, restart, 
stop, get the status, change the master key or the mode of operation. 
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The master key is used to encrypt all passwords in the registry database. 
When it is changed, all passwords in the database are re-encrypted. 


You can change the mode of the master security registry database to 
maintenance or back to normal from maintenance mode. When in 
maintenance mode, the database can be backed up. 


There are two additional Security Servers, the password strength service 
(Ispwsd) and the password synchronization service (pwsync). These 
password services are vital to the password maintenance processes in DSS. 
For more information on these services, refer to 6.2, “Password 
Management Considerations” on page 168. 


5.6.2.1 Setting the Preferred Security Replica 

By default, the method used by DSS Clients and Servers to locate a DSS 
Security Server is based on a random selection of bindings. In many 
environments, there will be a need for more control over the search order of 
Security Servers in the DSS cell. Such control would improve the logon 
performance of DSS clients since a Security Server closest to the DSS client 
would be given preference over a Security Server located over a WAN. This 
control is also important for DSS File and Print Servers since these servers 
contact a Security Server to authenticate legacy users during session 
establishment. Giving preference to a security replica located on the same 
LAN as the File and Print Server will improve the server’s logon 
performance and session establishment performance. 


In an environment where you have a DSS Domain Controller running 
RGYSYNC and a security replica, a PE_SITE file is automatically created (in 
\OPT\DCELOCAL\ETC\SECURITY) with an entry including the local Security 
Server (on the same machine) as well as the Master Security Server. This 
means that when a legacy client logs on to the Domain Controller, the 
Domain Controller can authenticate with its own security replica on behalf of 
the client (provided the security replica is running). 


Note: Performance improvements will only be for security operations of a 
“read-only” nature, since updates to security information will always have to 
be done at the Master Security Server. Two steps are necessary to set up a 
preferred Security replica: 


¢ First, an administrator needs to add an entry into an rpc profile, where a 
priority is associated with a given Security Server. The rpc profile used 
in the Preferred Security Replica design corresponds usually to a 
particular LAN profile. A pointer to a LAN profile is assigned to every 
host at configuration time. The LAN profile pointer is contained in the 
profile named /.:/hosts/{hostname}/profile. The exception is the slim 
client host which by default does not create a 
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/.:/hosts/{hostname}/profile. Instead, a 
/.:/slim.hosts/{hostname}/profile must be created manually by the 
administrator. 


- Second, at all workstations where the preferred replica setup will be 
used, run rbuildpe.exe to rearrange the pe_site file to reflect the 
priorities set in your profile. The rbuildpe.exe is also executed 
automatically when DSS is started. 

For multiple LAN profiles an automated script is provided: 


secrep.tcl 


The information required to complete the first step of setting up a Preferred 
Security Replica manually is as follows: 


¢ The interface ID for the Security Server. The current DCE Security 
Server interface ID used is: 
d46113d0-a848-11cb-b863-08001e046aa5,2.0 
You can verify this by looking at the cell-profile entry with the rs_bind 
annotation. The dcecp command is: 
dcecp -c rpcprofile show -a rs_bind /.:/cell-profile 

- The host name of the Security Server to be prioritized. To find the list of 
Security Servers in a cell, type: 
dcecp -c rpcgroup list /.:/sec 

* The name of the LAN profile for the machine you are configuring. This is 


set at configuration time. The OS/2 default is lan-profile. To find out what 
profile was configured type: 


dcecp -c rpcprofile list /.:/hosts/hostname/profile 


where hostname is your machine’s dce hostname. This will list the cell 
profile and the LAN profile. 


Here is an example of the LAN profile entry in the profile of host1: 


- The /.:/hosts/host1/profile contains the following rpc 
entry: 
6f264242-b9f8-11c9-ad31-08002b0dc035,1.0 
/.../lan-profile_X 
0 
LAN X 


where LAN X is an annotation that represents the LAN profile with the 
preferred replica information (/.../lan-profile_X). 
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If the host is a slim client an administrator must create a host profile, 
/.:/slim.hosts/{hostname}/profile, which will contain a reference to an 
existing LAN profile. The dcecp commands are: 


dcecp -c directory create /.:/slim.hosts 

dcecp -c directory create /.:/slim.hosts/{hostname} 
dcecp -c rpcprofile add - a LAN 

- 1 6f264242-b9f8-11c9-ad31-08002b0dc035,1.0 

- m/.:/{LAN profile} 

-p0 

/.:/slim.hosts/{hostname}/profile 


where: 
-a is an annotation where LAN indicates the name of the LAN profile, 
-i is the Interface ID of LAN profile, 


-m {LAN profile} specifies the CDS Global name of the LAN profile to 
use, 


-p is a priority from 0-7 with 0 being the highest, 


/.:/slim.hosts/{hostname}/profile is the host profile to be created 
where {hostname} is your machine dce_hostname. 


The above rpcprofile add command can also be used to change the 
reference to the LAN profile within the host profile. 

The dcecp command to initially prioritize a Security Replica or to change the 
priority of a Security Replica in a LAN profile is: 


dcecp -c rpcprofile add - a rsbind 

- i d46113d0-a848-11cb-b863-08001e046aa5,2.0 
- m /.:/subsys/dce/sec/{replica name} 

- p {0-7} 

/.:/{LAN profile} 


where: 
-a is an annotation 
-i is the Security Server Interface ID 
-mis the Security Server to prioritize 
{replica name} is the name of the Security Server to be prioritized 
-p is a priority from 0-7 with 0 the highest 
{LAN profile} is the LAN profile to be updated 


The above command will also create the LAN profile if it does not already 
exist. 
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The dcecp command to remove the priority of a Security Replica from a LAN 
profile is: 
dcecp -c rpcprofile remove -i d46113d0-a848-11cb-b863-08001e046aa5,2.0 


-m /.:/subsys/dce/sec/{replica name} 
/.:/{LAN profile) 


where: 
-i is the Security Interface ID, 
-mis the Security Server to be prioritized, 
{replica name} is the name of the Security Server to be prioritized, 
{LAN profile} is the LAN profile to be updated. 


The following is an example of the final setup of a LAN profile that reflects 
Security Server priorities. 


Under /.:/lan-profile X set the following rpc entries: 


d46113d0-a848-11cb-b863-08001e046aa5,2.0 
/...//subsys/dce/sec/ 

0 

replica 1 


d46113d0-a848-11cb-b863-08001e046aa5,2.0 
/...//subsys/dce/sec/ 

1 

replica 3 


d46113d0-a848-11cb-b863-08001e046aa5, 2.0 
/...//subsys/dce/sec/ 

1 

master 


d46113d0-a848-11cb-b863-08001e046aa5,2.0 
/...//subsys/dce/sec/ 

2 

replica 2 


In the above example replica 1 is the most preferred, where as the rest 
have a priority according to the priority field. Replicas with the same 
priority are selected randomly. 


5.6.3 Time Service 
DSS uses one or more Time Servers to ensure that the time is synchronized 
between all of the computers that are part of the network. This service is 
important because distributed operations often must be done in a 
time-ordered manner, and that is not possible unless all of the participating 
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systems have the same reference point. Additional information on Time 
services architecture can be found in “How Time Services Works” on 
page 39. 


Use Time Services to manage clock synchronization tasks for the Time 
Servers and Clerks (DTS entities) in a cell regardless of location. If the 
machines in a cell are more than five minutes out of synchronization, the 
clients cannot communicate with the servers. 


Note: The OS/2 operating system is not timezone aware, and thus does not 
automatically change the time when daylight-saving time is used. If 
daylight-saving time is used, then the time must be manually 
changed on each OS/2 machine that participates in the cell. 


The Time Service is managed through the Time Services folder shown in 
Figure 41. 
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Figure 41. Time Services 


156 


From the Context menu you can: 


¢ Start or restart the server 

* Check the status of the server 
¢ Synchronize the time 

- Set the time 


5.6.3.1 Working with Daylight Savings Time 

Use the procedures listed below when changing your OS/2 systems to and 
from Daylight Savings Time. Note that the four-character representation of 
the time zone variable TZ is recommended. 


Note: If you implemented the seven-character assignment for time zone, 
you must wait one hour before restarting the DSS services when 
changing from Daylight Savings Time. However, you can skip step 3 
in each of the procedures below. 
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These steps should be executed for all DSS Servers. Remember, a DSS 
client must be within five minutes of the Master Security Server’s time to log 
on successfully; so this procedure should also be followed at the client. 


¢ Changing to Daylight Savings Time: 
1. Stop all DSS services. 
2. Change the machine’s clock with the TIME command. 


3. Change the TZ variable in the CONFIG.SYS (for example, SET 
TZ=CDT5). 


4. Shut down the system and restart it. 
5. Restart the DSS services. 
¢« Changing from Daylight Savings Time 
1. Stop all DSS services. 
2. Change the machine’s clock with the TIME command. 


3. Change the TZ variable in the CONFIG.SYS (for example, SET 
TZ=CST6). 
4. Shut down the system and restart it. 


5. Restart the DSS services. 


5.7 Changing IP Addresses 


In general, when changing an IP address on a system in a non-DSS 
environment, the process is fairly straightforward. However, in DSS, IP 
addresses are stored in several places, particularly for servers. The first 
set of steps listed below should be used when changing IP addresses for 
Directory and Security Servers. Once the servers are changed, the second 
set of steps can be executed on the clients. 


Important 





Before continuing this procedure, please execute the following steps to 
ensure that the remaining steps are processed correctly. The 
instructions in the README.DCE omitted these steps. 


1. Go to the following directory: 


cd \opt\dcelocal\var\dir\cds 


2. Edit the CDSFILES.MAP file. Some of the directory paths may have a 
slash (/) instead of a backslash (\). Change all slashes to 
backslashes and save the file. 
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1. 


10. 


Remove knowledge of the clearinghouse on the machine. It is 
reinstated after the IP address is changed. If you do not know the name, 
use the command cdscp show cell /.: to get it. Then type 


cdscp clear clearinghouse /.:/<host_ch> 


If you have difficulty with this command, type the cdscp clearinghouse 
commands while cdsd is initializing itself. This is done by using another 
window to stop the running cdsd. When you restart the cdsd, type the 
cdscp command from your authenticated window while cdsd is coming 
up. 

Stop all DCE daemons on the machine. Type: 


dcestop 


. Switch to the drive where DSS is installed and remove the endpoint 


database. It is recreated on restart: 
erase <x>:\opt\dcelocal\var\dced\Ep.db 


where x is the drive where DSS is installed. 


. Remove the clerk cache. It is recreated on restart. Type: 


cd <x>:\opt\dcelocal\var\adm\dir\cds 

erase cdsclerk.* 

erase cdscache.ver 

erase cdscache.nnn (nnn is a 3-digit number) 


Edit the <x>:\opt\dcelocal\etc\security\pe_site file to reflect the new 
address so that security can start. 


. Remove old credentials: 


cd \opt\dcelocal\var\security\creds 
erase * 


. Change the IP address on your system (using TCPCFG). If you have a NET 


START SERVER command in your STARTUP.CMD, disable it for now, since 
the DCE services will not start properly since CDS is not completely 
functional yet. The REQUESTER service, which starts the DSSDCE 
service, will otherwise fail. 


Shut down and reboot your system. 


. Start the DCE daemons using the dcestart command. The gdad and 


dtsd daemons (if configured) do not start properly since the CDS is not 
completely functional yet. Start these daemons after the conversion 
process is completed. 


Since the CDS is not available, use the BIND_PE_SITE environment 
variable for security with the following commands: 
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11. 


12. 


13. 


14. 


SET BIND PE_SITE=1 
dcelogin cell_admin (or your cell administrator ID) 


Ensure that your ID and password are in upper-case. Otherwise, you 
will receive an error stating that the registry object was not found. 


Identify to the CDS the clearinghouse it is to manage (ensure that you 
use the same name as in the previous clear clearinghouse command ): 


cdscp create clearinghouse /.:/<host_ch> 


If you have difficulty with this command, type the cdscp clearinghouse 
commands while cdsd is initializing itself. This is done by using another 
window to stop the running cdsd. When you restart the cdsd, type the 
cdscp command from your authenticated window while cdsd is coming 
up. This command may appear to fail. Reissue the create command. If 
the message “Specified full name already exists” is displayed, the 
command was successful. 


Because the CDS Server was not aware of its clearinghouse when it 
was Started, the cdsadv process is also unaware of the existence of this 
clearinghouse. Rebuild the clerk cache with the following commands: 


dcestop cds_srv 
cd \opt\dcelocal\var\adm\dir\cds 
erase cdscache.* 
erase cdsclerk.* 
dcestart cds_srv 


The CDS and/or Security Servers are now reconfigured to use the new 
IP address. Reset the appropriate environment variable with the 
following command: 


Verify that you can now successfully access the namespace: 
cdsli -o 
You may see the following items: 


/.:/cell-profile 
/.:/lan-profile 
/.:/sec 
/.:/sec-vl1 


Update the server self entry in CDS with the following commands: 


rpccp unexport -i elaf8308-5d1f-11c9-91a4-08002b14a0fa,3.0 \ 
/.:/hosts/<server_name>/sel f 

rpccp export -i elaf8308-5d1f-11c9-91a4-08002b14a0fa,3.0 \ 
-b ncadg_ip_udp:<new_ip_addr>[135] \ 
/.:/hosts/<server_name>/sel f 
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Th 


is completes the server portion of the IP address change procedure. Use 


the following procedure on each DCE client in your cell if the IP address of a 
machine configured as a CDS and/or a Security Server has changed. 


{ 


2. 


Th 


. Stop all DCE daemons on the machine with the dcestop command. 


Remove the clerk cache since it has references to the CDS Server’s old 
IP address. The cache will be recreated on restart. Switch to the drive 
where DCE/DSS is installed and type: 

cd \opt\dcelocal\var\adm\dir\cds 

erase cds_cache.* 

erase cdsclerk_* 


. Change the <x>:\OPT\DCELOCAL\ETC\SECURITY\PE_SITE file so that 
the security client can find the Security Server on restart. 


. Remove the security credentials: 


cd \opt\dcelocal\var\security\creds 
erase * 


. Start the DCE daemons using the dcestart command. 
. Since CDS access is not restored yet, set the BIND_PE_SITE variable 
and then log in with the following commands: 
SET BIND PE_SITE=1 
dcelogin <your cell administrator id> 
. Inform the cdsadv process of the new IP address for the CDS Server. 
Type: 
cdscp define cached server <server_name> tower 
At this point, the client is fully aware of the server’s new IP address, so 
reset the environment variable and log in again: 
SET BIND PE_SITE= (nothing after the ’=") 
dcelogin <your cell administrator id> 
. Update client’s self entry in CDS (this step is not required for slim 
clients): 


rpccp unexport -i elaf8308-5d1f-11c9-91a4-08002b14a0fa,3.0 \ 
/.:/hosts/<client_name>/sel f 

rpccp export -i elaf8308-5d1f-11c9-91a4-08002b14a0fa,3.0 \ 
-b ncadg_ip_udp:<new_ip_addr>[135] \ 
/.:/hosts/<client_name>/self 


is completes the client portion of the server IP address change procedure. 


Make sure that all valid copies of your TCP/IP SETUP.CMD file have been 
updated properly. 
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5.8 Distributing the CDS Namespace 


The DSS Cell Directory Service database can be replicated and distributed. 
This means that the master copy of portions of the directory can exist on 
different directory servers in the cell. For a typical DSS cell, this feature can 
be used to reduce the impact of server outage to users across the cell as 
shown in Figure 42: 
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Figure 42. Cell Layout for CDS Partitioning 


After initial installation, the following are Cell Directory Service directories 
that are associated with the DSS domains and their workstations. 


root directory 
/.:/hosts (directory for Master security, Initial 
Directory servers) 
/.:/hosts/WKSTA1 


DSSDOM1 related directories: 
hosts directory for workstations 
/.:/hosts/WKSTA2 
/.:/hosts/WKSTA4 
resource domain directories 
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.:/resources/realms/DSSDOM1 
.:/resources/realms/DSSDOM1/files 
.:/resources/realms/DSSDOM1/printers 
.:/resources/realms/DSSDOM1/serial_devices 
.:/resources/realms/DSSDOM1/public_apps 
.:/subsys/realms/DSSDOM1 
.:/subsys/realms/DSSDOM1/servers 


~ mS “~~~ ~~~ OO 


DSSDOM2 related directories: 
hosts directory for workstations 
/.:/hosts/WKSTA3 
/.:/hosts/WKSTA5S 
resource domain directories 


/.:/resources/realms/DSSDOM2 
/.:/resources/realms/DSSDOM2/files 
/.:/resources/realms/DSSDOM2/printers 
/.:/resources/realms/DSSDOM2/serial_devices 
/.:/resources/realms/DSSDOM2/public_apps 
/.:/subsys/realms/DSSDOM2 
/.:/subsys/realms/DSSDOM2/servers 

The following are clearinghouse objects defined for each of the directory 

servers: 

/.:/WKSTAL_ch (initially all directories exist in this 


clearinghouse) 
/.:/WKSTA2_ch (at creation, the root directory is replicated 
to each additional CDS clearinghouse 
/.:/WKSTA3_ch 


Replicate and distribute the directories according to the DSS domain model 
illustrated. The first step is to replicate directories. 


All directories should be replicated to at least one other CDS server for the 
purpose of backup. You can use the command cdsli -rd to get a list of all 
current CDS directories. The following command replicates the domain 
related directories to the associated Additional Directory server for 
DSSDOM1: 


dcecp -c directory create 

.:/hosts/WKSTAZ 

.:/hosts/WKSTA4 
.:/resources/realms/DSSDOM1 
.:/resources/realms/DSSDOM1/files 
.:/resources/realms/DSSDOM1/printers 
.:/resources/realms/DSSDOM1/serial_devices 
.:/resources/realms/DSSDOM1/public_apps 
.:/subsys/realms/DSSDOM1 


~_ 
~™oSE “~~ ~~ 
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/.:/subsys/realms/DSSDOM1/servers 
} -replica -clearinghouse /.:/WKSTA2_ch 


Note: This is a single command line entry blocked for readability. Using 
OS/2 command line, this command may need to be broken up into 
smaller lists. The command would be repeated for DSSDOM2. 


The following command may be used to show all clearinghouses which 
contain a copy of a directory: 


cdscp show dir /.:/hosts/WKSTA3 CDS Replicas 


The next step is to make each domain clearinghouse the master copy of its 
domain related directories. This procedure should only be executed during 
a period of low activity. An alternative is to use cdscp to disable the server 
and cdsclerk to prevent updates. However, this operation requires 
commands be executed locally at each CDS server workstation. Always 
make sure that the replica is up to date with the master before switching the 
master and read-only roles. This is done with the following skulk 
(synchronize) command: 


dcecp -c dir sync /.:/hosts/WKSTA2 


This command requires that all replicas of this directory be available. The 
command will not return until the operation is complete or fails. Now 
change the master/readonly clearinghouse roles for this directory: 


cdscp set dir /.:/hosts/WKSTA2 to new epoch 
master /.:/WKSTA2_ch 
readonly /.:/WKSTA1_ch 


The preceding two commands would be repeated for each directory related 
to the DSSDOM1 domain and then for each directory of the DSSDOM2 
domain. Two things have been accomplished with this procedure. First, the 
workload is distributed by directing domain specific updates and high 
confidence requests to the local domain’s directory server (as opposed to 
DCE’s random method of workload distribution). Second, workstation 
availability across the cell is improved by reducing the Initial Directory 
Server as a single point of failure. For planned outage of a domain 
directory server, the procedure could be reversed for that domain’s related 
directories during the outage. 


5.9 Recovering when Master Servers are Unavailable 


It is still possible to start DSS clients and servers when the master directory 
(actually master clearinghouse) server and/or master security server are 
unavailable. In fact, most DSS components are able to start when either of 
the master databases are unavailable. The exception is DTS (Distributed 
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Time Service), but workarounds are possible for this component. These 
procedures apply to DSS on OS/2. The procedures for starting DCE servers 
on AIX workstations should work as well, but have not been tested. 


5.9.1 General Considerations 
The following minimum requirements apply: 
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At least one DCE security replica must be active in order to start the 
security component of DSS clients. Only the security client of the 
master security server will start without a security server active. 


A CDS (Cell Directory Service) server is required (initial or additional) 
with all required directories replicated to the active clearinghouse. It is 
not necessary for the master copy of directories to be available except 
for Distributed Time Service (DTS). The required directories will be 
identified with individual configurations below. 


Note: APAR 1IC17472 is required for DSS File and Print servers to start 
when the master directory clearinghouse is unavailable. 


The following items apply specifically where DTS is in use: 


When DTS is used, DSS server (DCE or File/Print) workstations will have 
a DTS client or server configured. Non-server DSS clients synchronize 
their time with the cell only at startup. Workstations with the DTS client 
will periodically synchronize their time. 


In order to start a DTS client or DTS server component of DSS, the 
master CDS clearinghouse of the “hosts” directory for its workstation 
must be available. This directory name is the hostname specified 
during DSS configuration and is located in the /.:/hosts CDS directory. If 
the master is not available, an error “dtsd server still isn’t accepting 
RPC connections after 150 seconds” is recorded in 
OPT\DCELOCAL\VAR\SVC\ERROR.LOG. 


When configuring DSS, the startup option “Time Synchronization 
server’s address” specifies the address of the DTS server which the 
workstation will use to synchronize its time at startup. If this time server 
is not available, the workstation will not synchronize time with the cell. 
If the time is within 5 minutes of the cell, the startup will complete 
successfully. The error” Couldn’ t obtain binding to remote time server” 
is logged in OPT\DCELOCAL\VAR\SVC\ERROR.LOG. If the time 
difference is greater than 5 minutes, DSS startup will fail with the 
message “Unable to start security client”. The 
OPT/DCELOCAL/VAR/SVC/ERROR.LOG will contain “Call to a 
sec_login_xxx function failed, status=0x14129025”. The 0x14129025 
interprets as “Clock skew too great”. In this case, manual correction of 
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the workstation time is necessary to start DSS while the DTS server is 
unavailable. 


5.9.2 Starting DSS Clients or Servers without DTS 
There is no special procedure required to start this DSS configuration. Use 
the normal NET START REQ command. If you are not sure about configuration, 
at an OS/2 command prompt issue SHOWCFG to get a list of the configured 
DSS or DCE components. The following is an example of the SHOWCFG 
output: 
[C:\]showcfg 


Gathering component state information... 
DCE Component Summary for Host: OCLAB1 


Component Configuration State Running State 
Master Security server Configured Not Running 
Security client Configured Not Running 
Directory client Configured Not Running 
DTS Local server Configured Not Running 
Password Synchronization server Configured Not Running 
Password Strength server: Ispwsd Configured Unknown 
Audit server Configured Not Running 
The DCE component summary is complete. 

[c:\] 


5.9.3 Starting DSS Clients or Servers with DTS 
If you are unable to start the DTS component for one of the reasons listed 
in 5.9.1, “General Considerations” on page 164, and it is acceptable to 
operate the workstation with manually managed workstation time, then use 
the following procedure: 


1. Open the IBMLAN\IBMLAN.INI file and check the “WRKSERVICES” entry 
for LAN requester services that need to be started. 


2. Enter the following command including any services EXCEPT the 
DSSDCE service. If there are no other services besides DSSDCE, the 
/WRKSERVICES: is still necessary. 


NET START REQ /WRKSERVICES:[servicel service2 ...] 
3. Use the SHOWCFG command to get a list of DCE configured components. 


4. Use the DCESTART -? command to get a list of DCE component keywords 
(in fact, the same keywords are available for the DCESTOP command). 
The following text is the output of this command: 


Usage: dcestart [-w start_mode] [components] 
where: 
-w start_mode The mode in which to start the DCE daemons 
(none, single, separate) 
[components] are: 
all All configured components (default) 
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client 
slim_client 
cds client 
cds_svr 
cds_second 
gda_svr 
dts_client 
dts_local 
dts_global 
sec_client 
sec_svr 
sec_replica 
sec_audit 
pw_sync_svr 


pw_strength_svr 


dfs_client 
ems 


All configured client components 
Slim client (Directory clerk) 
Directory client 

Directory server 

Additional Directory server 

GDA server 

DTS client 

DTS Local server 

DTS global server 

Security client 

Master Security server 

Security Replica server 

Audit server 

Password synchronization server 
Password strength server 

DFS client 

EMS 


5. Enter the following command to start the DCE components. 


DCESTART <component_name> 


6. If configured for a DSS File and Print server, then use the NET START SRV 
command. 


Note: APAR 1IC17472 is required for DSS File and Print servers to start 
when master directory clearinghouse is unavailable. 
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Chapter 6. Using DSS in Heterogeneous Environments 


The Directory and Security Server for OS/2 Warp is based on the standard 
Distributed Computing Environment Version 1.1 specifications. While a 
standard DSS install will use OS/2-based servers for the Security and 
Directory services, you can use DCE Servers running on other platforms, 
such as AIX and MVS. This chapter discusses some important 
considerations when implementing DSS in a heterogeneous environment. 





6.1 Version Requirements 

DSS requires a DCE Security Server at the OSF/DCE Version 1.1 level or 
greater. All other servers, such as Time Servers and Directory Servers, can 
be at the OSF/DCE Version 1.0.3 release level or later. This DCE Security 
Server V1.1 requirement is due to the fact that DSS makes extensive use of 
Extended Registry Attributes that were not implemented on the DCE Security 
Server until Version 1.1. 
In general, the following DCE Servers are supported: 

¢ AIX DCE 1.3 Servers 

¢ AIX DCE 2.1 Servers 

¢« MVS/ESA OpenEdition DCE 

¢ OS/390 DCE Base Services 

* OS/390 Security Server 

* OS/390 DCE DFS 
The following DCE products should work with DSS over OS/2 LAN Server or 


OS/2 Warp Server. This means that no testing has been done, but they 
should interoperate: 


- Digital Equipment Corporation DCE Servers for NT(1.03) 
¢ Transarc Solaris DCE and DFS Servers (1.1) 

¢ HP DCE Security Server (1.1) 

* SCO DCE 1.0.3 


The following DCE Clients are supported with some restrictions: 
« IBM DCE Client for Windows V 1.0 with CSD 
- OS/2 DCE 1.0 Client 
¢ AIX DCE 1.3 Clients 
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* AIX DCE 2.1 Clients 

¢ Digital Equipment Corporation DCE Client for Windows NT 

* MVS Client (1.1) 

* AS/400 Client 1.0.3 

« HP Client 1.0.3 or 1.1 

« Windows NT with NT’s RPC implementation 

* Windows 95 with MS toolkit for Windows NT RPC 

- Gradient PC-DCE for Windows 3.1, Windows 95, Windows NT 





6.2 Password Management Considerations 


If your implementation will not use a DSS Master Security Server, that is, if 
you will be using an AIX, MVS, or any non-OS/2 Master Security Server, 
please read this section. After discussing the password change 
mechanisms, we discuss some important options which need to be selected 
when installing DSS. Also, there may be additional DCE components 
needed on the Security Server to fully support DSS. 


In the DCE architecture, there are two additional Security Server functions 
that play an important role, particularly in DSS. These functions are the 
password strength server (lspwsd) and the password synchronization server 
(pwsync). These password servers are vital to the password maintenance 
processes. Figure 43 shows how the password servers coordinate the 
processes. 





PWSYNC ro LSPWSD 


1) 


LSPWSYNC 








Figure 43. Password Servers 


168 


Inside DSS for OS/2 Warp 


The process that occurs in Figure 43 is as follows: 


1. A new user ID is created or a password change request is made by an 
existing account. 


2. The SECD process on the Security Server passes the request on to the 
PWSYNC process on a DSS Server, which checks the details on the 
account. 


PWSYNC then passes the password to the LSPWSD strength server (in a 
non-DSS cell, the strength server is called PWDSTRED). Here, the 
password is checked against the standard OS/2 LAN Server password 
rules. If all the rules have been adhered to, then the password is passed 
to the LSPWSYNC. 


3. LSPWSD checks the password history for duplications. If there have not 
been any duplications, this password is accepted. If any of the previous 
services reject the password, the change is rejected. 


LSPWSYNC then synchronizes the DCE password with the foreign 
registry. In this case, the 1s_encr_passwd ERA of the user is updated with 
the OS/2 LAN Server-encrypted equivalent of the new user password. 


When implementing DSS with a non-DSS Master Security Server, you must 
autostart the DSS Password Synchronization service on exactly one DSS 
Server in the cell. Refer to Table 6 on page 82 for a description of the 
Autostart options. 


As shown in Figure 43 on page 168, The SECD process is one system, the 
Master Security Server. The PWSYNC, LSPWSYNC and LSPWSD processes 
run on the DSS Server in which the DSS Password Synchronization service 
was selected. Because these two systems need to communicate security 
information, their encryption methods must match. For example, if you have 
a DSS Server (running DSS Password Synchronization) using DES 
encryption (in North America), you must also ensure that the same capability 
is present on the Master Security Server. In AlX and probably also other 
vendor implementations, you need to purchase a separate feature that adds 
DES and CDMF encryption capabilities, since the default is usually packet 
integrity. Another option is to change the DSS mechanisms from packet 
privacy to packet integrity, which should work with most non-DSS Security 
Servers. 


Note: The Password Synchronization server included with DSS cannot be 
managed through the DSS Administration GUI. 
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6.3 Adding DSS to an Existing DCE Cell 


Once you understand the considerations from the previous section, 
installing DSS Domain Controllers into an existing cell is a fairly 
straightforward process and varies only slightly from installation into a DSS 


cell. 


1. 


To reiterate: 


When installing a DSS Master Security Server, the DSS Password 
Synchronization Server is installed automatically, whether or not the 
DSS Password Synchronization box is checked on the Autostart panel of 
the Configuration notebook. However, since the Master Security Server 
is not on DSS, you must select the Password Synchronization service on 
the first DSS Server installed into the cell. 


It is very likely that the cell administrator ID for the existing cell will 
have a lowercase or a mixed-case user ID and password. The Directory 
and Security Server for OS/2 Warp, however, maps all user IDs and 
passwords to uppercase, in order to maintain compatibility with existing 
legacy OS/2 LAN Server user IDs and passwords. Please read through 
6.4, “Cell Administrator ID Considerations” on page 171 before starting 
the following installation procedure. 


The DSS installation GUI allows for this situation during the install 
process as follows: 


a. During installation of the DSS Domain Controller, click on the User 
ID and Password page of the Configuration notebook. 


b. Make sure the Authorize full configuration into the cell box is 
checked. 


c. Click on the Mixed-Case ID button. 


d. This will bring up a panel to allow you to enter the correct, existing 
cell administrator user ID (say, cell_admin) and password for the 
cell. 


e. Click OK to return to the user ID and password panel. 


f. Enter a new user ID and password for a cell administrator (say, 
CELLADMIN). This will be in uppercase. 


g. Continue with the installation as normal. The installation process 
will create an Alias for the cell_admin user ID. Whenever 
CELLADMIN logs onto a DSS machine, then CELLADMIN will receive 
the same rights as the cell_admin ID. The authority of this user ID is 
used to configure the DSS Server into the DCE cell. 


3. DSS can use either DES or CDMF encryption. When installing the first 


DSS Server (and the pwsync server) into an existing cell, it is essential 
that the existing Master Security Server supports the same level of 
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encryption being installed. Otherwise, the secd service on the Master 
Security Server will not be able to communicate with the new pwsync 
service. An upgrade to the DCE code in the existing cell may be 
necessary. See 6.2, “Password Management Considerations” on 
page 168 for further details of the Password Synchronization Server. 


6.4 Cell Administrator ID Considerations 


When installing DSS into an existing DCE cell, the cell administrator user ID 
and password are likely to be in mixed- or lower-case. This presents a 
problem for DSS which uses upper-case IDs and passwords. The solution 
for this problem is to create an alias of the cell administrator ID using 
upper-case characters for the ID and password. For more information about 
principal aliases, refer to “Maintaining Aliases for Principals and Groups” in 
the online DCE for OS/2 Warp: Administration Guide. 


The following is a step by step procedure for installing DSS using an alias of 
the cell administrator: 


1. During the installation of the first DSS configuration, create the cell 
administrator alias. When User ID and Password is selected on the 
Configuration menu, click on Mixed-case ID and enter the current cell 
administrator ID and password in the pop-up menu. Enter the DSS user 
ID (alias) and password in the User ID and Password menu. Complete 
the installation, as described in 6.3, “Adding DSS to an Existing DCE 
Cell” on page 170. 


2. After completion of the first DSS installation and before any other DSS 
systems are installed, add the DSS cell administrator user ID (alias) to 
the necessary cell administrator-equivalent groups as follows: 


a. Log in using the original user ID. If this is done at the DSS OS/2 
workstation, type dcelogin userid password 


b. Type dcecp -c principal show <originaluserid> -all to get a list of 
groups of which the cell administrator is a member. 


c. Type dcecp -c principal show <aliasuserid> -all to get a list of 
groups of which the alias cell admin is a member. For each group 
name listed for the original user ID and not in alias user ID, type 
dcecp -c group <groupname> -m <aliasuserid> 


3. For subsequent DSS installations, the alias user ID should be used as 
the DSS cell admininstrator user ID. DO NOT enter the original 
mixed-case ID. 
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6.5 LAN Server/400 and LAN Server for AIX 
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IBM LAN Server for AIX (LSX) is functionally equivalent to OS/2 LAN Server 
Version 3 SMB protocols. LSX is no longer marketed or supported by IBM. 
LSX does not support DSS. However, since it can be an additional server in 
an OS/2 LAN Server domain, it can also be a legacy-based additional server 
in a DSS resource domain. This has been informally tested and basic file 
and print functions were found to work properly. However, it is not officially 
supported. 


Some customers may also have AIX Connections installed. Although AIX 
Connections does not support DSS, legacy clients and DSS Clients can still 
access resources because AIX Connnections supports SMB requests. 


IBM LAN Server/400, an implementation of OS/2 LAN Server support on the 
AS/400, is also based on OS/2 LAN Server Version 3 SMB protocols. This 
product synchronizes user IDs and passwords from the AS/400 database 
down to the LAN Server database so that user IDs and passwords can be 
managed by the AS/400 administrator. This is a one-way synchronization. 
It is possible for LAN Server/400 to be an additional server in an OS/2 LAN 
Server domain, and thus could be a legacy additional server in a DSS 
resource domain. However, the capability to receive updated user 
information from the AS/400 database is lost. 
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Appendix A. Introduction to DCE 


The Distributed Computing Environment (DCE) is an important prerequisite 
concept in order to understand the benefits that the Directory and Security 
Server for OS/2 Warp can provide to the existing LAN environment. This 
chapter provides a basic overview of the services provided by the 
Distributed Computing Environment. It is not intended to be a source of 
extensive information about DCE. The reader may refer to the publications 
listed in Appendix F, “Related Publications” on page 241, for more 
information. 


A.1 Introduction to the Distributed Computing Environment 


DCE is an architecture, a set of open standard services and associated APIs 
used to support the development and administration of distributed 
applications and environments. In other words, DCE is an “enabling 
technology” or a tool that is used to produce the end result, which is a 
distributed application. 


DCE is the result of work from the Open Systems Foundation (now called the 
Open Group), a collaboration of many hardware vendors, software vendors, 
customers, and consulting firms. The OSF began in 1988 with the purpose 
of supporting the research, development and delivery of vendor-neutral 
technology and industry standards. One such standard developed was the 
Distributed Computing Environment (DCE), which is the name for a set of 
integrated services designed to support the development and use of 
distributed applications in a multiplatform, multivendor environment. DCE 
Version 1.0 was released in January 1992. 
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Figure 44. DCE Architectural Components 





As shown in Figure 44, DCE includes the following major services: 


* Threads 

¢ Remote Procedure Call 
* Cell Directory Service 

¢* Global Directory Service 
* Security Service 

- Distributed Time Service 
¢ Distributed File Service 


All the services above have Application Program Interfaces (APIs) that allow 
the programmer to use these functions. These services are described in 
more detail in the following pages. 





A.2 DCE Threads 


Traditional applications (written in languages like C, COBOL, PASCAL, 
BASIC, FORTRAN, and others) have many lines of programming code which 
usually execute in a sequential manner. At any time, there is one point in 
the program that is executing. This can be defined as single threading. A 
thread is a single unit of execution flow within a process. Better application 
performance can often be obtained when a program is structured so that 
several areas can be executed concurrently. This is called multithreading. 
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The capability of executing multiple threads is also dependent on the 
operating system. For example, OS/2 provides multithreading facilities for 
the programmer; Microsoft Windows 3.x does not. 


In a Distributed Computing Environment based on the Client/Server model, 
threads provide the ability to perform many procedures at the same time. 
Work can continue in another thread while the thread waiting for a specific 
response is blocked. A server may issue concurrent procedure call 
processing. While one server thread is waiting for an I/O operation to finish, 
another server thread can continue working on a different request. 


To function well, thread support needs to be integrated into the operating 
system. If threads are implemented at the application software level instead 
of within the operating system, performance of multithreaded applications 
may seem slow. 


The DCE Threads APIs are either user-level (in operating systems that don’t 
support threads, such as Windows 3.x) or kernel threads (such as AIX and 
OS/2). They are based on the POSIX 1003.4a Draft 4 standard. Since OS/2 
also has threads, the programmer can use DCE Threads or OS/2 Threads. 
DCE Threads can be ‘mapped’ onto OS/2 Threads through special 
programming constructs. However, in order to write portable applications 
that can run on different platforms, only DCE Threads should be used. In 
many cases, there is little performance difference resulting from this 
mapping. 





A.3 DCE Remote Procedure Call 


The DCE Remote Procedure Call (RPC) architecture is the foundation of 
communication between the client and server within the DCE environment. 
RPCs provide the ability for an application program’s code to be distributed 
across multiple systems, which can be anywhere in the network. 


An application written using DCE RPCs has a client portion, which usually 
issues RPC requests, and a server portion, which receives RPC requests, 
processes them, and returns the results to the client. RPCs have three 
main components: 


« The Interface Definition Language (IDL) and its associated compiler. 
From the specification file, it generates the header file, the client stub 
and the server stub. This allows an application to issue a remote 
procedure call in the same manner that it would issue a local procedure 
call. 


« The network data representation, which defines the format for passing 
data such as input and output parameters. This ensures that the 
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bit-ordering and platform-specific data representation can be converted 
properly once it arrives at the target system. This process of preparing 
data for an RPC call is called marshalling. 


¢- The run-time library, which shields the application from the details of 
network communications between client and server nodes. 


The application programmer may choose to use multiple threads when 
making RPC calls. This is because an RPC is synchronous—that is, when an 
RPC call is made, the thread which issued the call is blocked from further 
processing until a response is received. 


Remote Procedure Calls can be used to build applications which make use 
of other DCE facilities, such as the Cell Directory Service (CDS) and the 
Security Service. The CDS may be used to find servers or to advertise a 
server’s address for client access. The Security Service might be used to 
make Authenticated RPCs which enable various levels of data integrity and 
encryption using the Commercial Data Masking Facility (CDMF), Data 
Encryption Standard (DES), and other functions such as authorization. 





A.4 DCE Directory Services 


When working in a large, complex network environment, it is important to 
keep track of the locations, names and services (and many other details) of 
the participants in that network. It is also important to be able to access 
this information easily. To enable this, information should be stored in a 
logical, central location and should have standard interfaces for accessing 
the information. The DCE Cell Directory Service does exactly this. 


The DCE Cell Directory Service has the following major components: 


* Cell Directory Service (CDS) 

* Global Directory Service (GDS) 

¢ Global Directory Agent (GDA) 

* Application Program Interface (API) 


A.4.1 Cell Directory Service 
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The Cell Directory Service manages a database of information about the 
resources in a group of closely cooperating hosts, which is called a cel//. The 
Directory Service database contains a hierarchical set of names which 
represent a logical view of the machines, applications and resources within 
the cell. These names are usually directory entries within a directory unit. 
Often, this hierarchical set of names is also called the namespace. The cell 
requires at least one DCE Server configured with the Cell Directory Service 
for proper function. 
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The CDS has two very important characteristics—it can be distributed, and it 
can be replicated. Distributed means that the entire database does not have 
to reside on one physical machine in the cell. The database can logically 
be partitioned into multiple sections (called replicas), and each replica can 
reside on a separate machine. The first instance of that replica is the 
Master Replica, which has read/write access to it. What if you want to have 
a backup copy of one of these replicas? Each replica can be replicated. 
That is, you can make a copy of this replica on a different machine. This is 
called a read-only replica. 


Replicas are stored in a clearinghouse. A clearinghouse is a collection of 
Directory Replicas at a particular server. All directories must be part of a 
clearinghouse (although not necessarily the same one). 


The Cell Directory Service also makes use of the DCE Security Service. 
When the CDS initializes, it must authenticate itself to the DCE Security 
Service. This prevents a fraudulent CDS from participating in the existing 
cell. 


Figure 45 on page 178 shows a generic namespace for a cell called occell. 
As you can see, the namespace is organized in a hierarchical manner. 


Appendix A. Introduction to DCE 177 


global root Live 


occell (/.:) 





lan-profile sec fs subsys_ cell-profile hosts 
The "sec" junction realms host1 host2 host3 


points to the security 
namespace -—+— 
resdom1 resdom2 resdom3 


The “fs” junction points 


to the DCE File System Not all CDS entries are listed 
namespace 


Figure 45. Generic CDS Namespace for occell 


A.4.2 Global Directory Service and Agent 
The Cell Directory Service is responsible for knowing where resources are 
within the cell. However, the cell can be part of a larger hierarchical 
namespace, called the Global Directory namespace. The Global Directory 
Service (GDS) allows us to resolve the location of resources in foreign cells. 
This is the case when a company wants to connect their cells together, or to 
the Internet. 


In order to find a resource in another cell, a communication path needs to 
exist between the two cells. This communication path can currently be one 
of two types: 


* CCITT X.500 

« Internet Domain Name Services (DNS) 
X.500 is an international standard which provides a model for an overall 
namespace and management in a global environment. It is based on the 


Open Systems Interconnect (OSI) protocol. Internet Domain Name Services 
is the well-known mechanism for naming and resolution of TCP/IP 
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hostnames. Of the two, Internet DNS is more established in the computing 
industry. 





Figure 46. Global Directory Structure 


How is intercell communications accomplished? Another component, the 
Global Directory Agent, is also required. The Global Directory Agent (GDA) 
is the intermediary between the local cell and the Global Directory Service. 
In Figure 46, if the CDS does not know the location of a resource, it tells the 
client to ask the GDA for assistance. The GDA knows what global 
namespace it is connected to and queries the GDS (either DNS or X.500) for 
the name of the foreign Cell Directory Server to communicate with. Once in 
direct communication with the foreign Cell Directory Server, the network 
name of the resource requested can be found. 


As you can see, the Global Directory Agent is the component that provides 
communications support for either DNS or X.500 environments. 


Note: The Global Directory Agent that ships in the first release of the 
Directory and Security Server for OS/2 Warp supports only Internet DNS, not 
X.500. 





A.5 DCE Security Service 


Security is always a concern in a networked environment. In a large, 
distributed environment, it is even more crucial to ensure that all 
participants are valid users who access only the data they are permitted to 
work with. Two primary concerns are authentication and authorization. 
Authentication is the process of proving or confirming the identity of a user 
or service. Authorization is the process of checking a user’s level of 
authority when an access attempt is made. If a user tries to make a change 
and read-only access has been granted, then the update attempt will fail. 
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The DCE Security Service ensures secure communications and controlled 
access to resources in this distributed environment. It is based on the 
Massachusetts Institute of Technology’s Project Athena, which produced 
Kerberos. Kerberos is an authentication service that validates a user or 
service. The DCE Security Service is based on Kerberos Version 5.1, with a 
few enhancements. 


Since the DCE Security Service must be able to validate users and services, 
it must also have a database to hold this information. This is indeed the 
case. The DCE Security Service maintains a database of principals, 
accounts, groups, organizations, policies, properties, and attributes. This 
database is called the registry. See Figure 2 on page 16 for a pictorial 
representation of the registry tree. 


The DCE Security Service consists of several components: 


Authentication Service Handles the process of verifying that principals 
are correctly identified. This also contains a 
Ticket Granting Service, which allows the 
engagement of secure communications. 


Privilege Service Supplies a user’s privilege attributes to enable 
them to be forwarded to DCE Servers. 


Registry Service Maintains the registry database, which contains 
accounts, groups, principals, organizations, and 
policies. 


Access Control List Facility Provides a mechanism to get a principal’s 
access request against the access controls for 
the resource. 


The Login Facility Provides the environment for a user to log in 
and initialize the security environment and 
credentials. 


These services allow for user authentication, secure communication, 
authorized access to resources, and proper enforcement of security. 


The DCE Security Service also communicates with the Cell Directory Service 
to advertise its existence to the other systems which are part of the cell. 
The DCE Security Service also uses the Distributed Time Service to obtain 
timestamps for use in many of its processes. 


A.5.1 Authentication Service 


The role of this service is to allow principals to positively identify 
themselves and participate in a DCE network. Both users and servers 
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authenticate themselves in a DCE environment, unlike LAN Server where 
only users are authenticated. There are two distinct steps to authentication. 
At initial logon time, the Kerberos third-party protocol is used within DCE to 
verify the identity of a client requesting to participate in a DSS network. 
This process results in the client obtaining credentials which form the basis 
for setting up secure sessions with DSS Servers when the user tries to 
access resources. 


In OSF DCE Version 1.1, the idea of preauthentication is introduced, which is 
not present in the Kerberos V5 authentication protocols. Preauthentication 
protects the Security Server from a rogue client trying to guess valid user 
IDs in order to hack into the system. There are three protocols for 
preauthentication: 


1. No preauthentication—this is provided to support DCE clients earlier 
than Version 1.1. 


2. Timestamps—this is used by DCE Version 1.1 Clients who are unable to 
use the third party protocol. An encrypted timestamp is sent to the 
Security Server. The timestamp is decrypted and if the time is within 5 
minutes, the user is considered preauthenticated. This option should be 
specified for cell administrators and non-interactive principals. 


3. Third Party—this is the default used by DCE Version 1.1 Clients. It is 
similar to the timestamps protocol, but additional information about the 
client is also encrypted in various keys. 


Note: For additional information on preauthentication and 
authentication, refer to the online DCE Administration Guide, the 
redbook titled DCE Cell Design Considerations., SG24-4746, or the 
following Transarc Web site for online DCE Version 1.1 documentation: 


http://www. transarc.com/afs/transarc.com/public/www/Public/Documentation/dce/1.1/ 


The authentication features and facilities that verify principal identities and 

enable them to establish secure sessions with each other will be described. 
Figure 47 on page 182 illustrates the major authentication steps which are 

described in more detail. 
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Figure 47. DCE Authentication and Login Using Third-Party Protocol 


1. The user issues a request to log into the cell. However, the user must 
first be authenticated. The client creates two random conversation keys, 
one of them based on the machine session key. The Login Facility on 
the client then uses these keys and the supplied password to encrypt a 
request for an authentication ticket (Ticket Granting Ticket, or TGT) from 
the Security Server. 


2. The Authentication Service (AS) on a Security Server receives the 
request. The AS looks up the machine session key from the registry to 
decrypt the request (note that by knowing the machine session key the 
Security Server proves to be valid for the cell. A false server would not 
know the machine session key). If the decryption is successful and the 
timestamp is within five minutes, the AS encrypts a TGT using one of the 
client conversation keys provided. When successful, this encrypted TGT 
is returned to the client. 


3. The client receives the TGT envelope and decrypts it using one of the 
client conversation keys it provided. Also included is a conversation key 
for the AS. Note that the TGT itself is encrypted with a conversation key 
of the AS. This valid TGT is proof that the user is now authenticated. 


4. Now the user needs its authorization credentials, known as Extended 
Privilege Attribute Certificate (EPAC), from the Privilege Service (PS). 
So, it must construct a Privilege Ticket Granting Ticket (PTGT) request to 
retrieve this from the PS. To communicate with the PS, the client sends 
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a request to the AS to contact the PS. This request is encrypted with 
the conversation key of the AS. 


5. The AS receives this request. Using the secret key of the PS, the AS 
generates a conversation key for the client to use when contacting the 
PS. This is returned to the client and encrypted again with the AS 
conversation key. The client receives the envelope and decrypts it 
(using the conversation key) and discovers the conversation key for the 
PS. The client can now send a Privilege Service ticket to the PS. 


6. The PS receives the request and decrypts it with its secret key 
successfully. This proves that the service ticket is legitimate, which also 
implies that the AS involved is also legitimate. From this, the PS knows 
that the client and the AS are valid. The PS constructs the EPAC, which 
lists the user’s standard and extended registry attributes, including 
group membership. The PS creates more conversation keys and sends 
the EPAC and other information in an encrypted PTGT envelope to the 
client. 


7. The client decrypts the PTGT envelope using the PS conversation key. 
Also, the client has the conversation key information and an encrypted 
PTGT (which the client cannot decrypt, since it is encrypted using the AS 
secret key). 


8. Now, the client wants to contact an application server. To do so, it sends 
the PTGT to the AS and requests a service ticket for the application 
server. The AS receives the PTGT and decrypts it to obtain the EPAC 
information. It encrypts the EPAC information with the secret key of the 
application server and also provides a conversation key for the 
application server. This information is encrypted with the conversation 
key of the AS (which the client knows) and is returned to the client. 


9. The client decrypts the envelope and discovers the application server 
conversation key. Using this key, it can now contact the application 
server. 


In addition to the extensive use of secret keys during logon, third-party 
authentication makes use of timestamps to ensure that the conversation is 
protected against intruders and eavesdropping. Timestamps make 
impersonation techniques, such as record and playback, ineffective. Also, 
the actual user password entered at logon time does not flow to the server 
as such. Instead, it is used as an encryption key for the initial logon 
messages which are then decrypted by the Security Server using its own 
copy of the password stored in the registry database. 


If the Security Server is not able to authenticate the client for some reason, 
such as entering an invalid password, an error is returned and the logon is 
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terminated. However, if the exchange completes with the client being 
successfully authenticated, the Security Server returns credentials which are 
then used by the client to establish sessions with DSS Servers (discussed 

in A.5.2, “Mutually Authenticated Sessions”). These credentials contain 
information in the form of a Privilege Ticket Granting Ticket (PTGT) and 
Extended Privilege Attribute Certificate (EPAC): 


EPAC This is a validated list supplied by the Security Server containing 
the client’s name, groups the client belongs to, and the Extended 
Registry Attributes for the authenticated client (if any were 
defined and associated with their account). A client must present 
its EPAC (acquired during third-party authentication) to any 
server the client wishes to connect to in order to access its 
resources. 


PTGT A PTGT is a Privilege Ticket Granting Ticket. It contains the 
EPAC, which has all the relevant information about a user (UUID, 
group membership, ERAs, and so on). The PTGT is what is 
actually passed from a DSS Client to a DSS Server when it needs 
to access resources (for example with the NET USE command). 


The DSS Security Services use two OSF DCE 1.1 features, ERAs and 
GSSAPI, to achieve LAN Server integration into a full DCE compliant 
environment. Extended Registry Attributes (described in A.5.3, “Registry 
Service in DSS” on page 187 are used to support all OS/2 LAN Server 
unique attributes (that is, not common to DCE) such as logon time and logon 
assignments. These attributes, which are stored in the registry database, 
get attached to user accounts and form part of the EPAC obtained when the 
client is authenticated at logon time. 


GSSAPI is the Internet Engineering Task Force’s (IETF) Generic Security 
System Application Programming Interface. GSS provides a standard set of 
APIs for applications that use non-RPC-based communications to interface 
with DCE Security Services. As authentication in DSS utilizes SMB- as well 
as RPC-based communication protocols, DSS makes extensive use of GSS 
in its implementation of the DCE Authentication Services. DSS Clients and 
Servers use GSSAPIs for establishing their identities (credentials) and 
authentication. The GSS available with DSS includes the standard routines 
used as well as OSF DCE 1.1 extensions. These provide support for EPACs, 
delegation (limited use in DSS) and mapping DCE logon contexts to GSSAPI 
credentials. 


A.5.2 Mutually Authenticated Sessions 


Prior to accessing a resource, a user must first get authenticated by a 
trusted third-party (security services) as described in the section above. 
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Once a successful logon completes, the user can access resources on DSS 
File and Print Servers by issuing a NET USE command. 


When the client requests access to a DSS Server, DSS attempts to establish 
a mutually authenticated session between the DSS Client and the DSS 
Server. If the mutually authenticated session succeeds, DSS proceeds to 
authorization, if necessary. If the session fails, DSS returns an error to the 
client. 


To establish the mutually authenticated session, DSS uses a combination of 
the Server Message Block (SMB) protocol and the DSS Security Protocol. 
The SMB protocol is an X/Open standard that LAN Server and many other 
network software products use to establish sessions. When using the SMB 
protocol, the client and server must negotiate a security protocol to use in 
securing the session. A DSS Client and DSS Server select the DSS Security 
protocol. The DSS Security protocol uses the DCE Generic Security Service 
Application Programming Interface (GSSAPI) protocol and offers a higher 
degree of protection than other security protocols that can be negotiated 
with SMB. 


Figure 48 shows how DSS uses the SMB and GSSAPI Security protocols to 
establish a mutually authenticated session between a DSS Client and DSS 
Server when the client requests access to the server. 
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Figure 48. DSS Authentication with GSSAPI 


1. The client sends an SMB request to the server to start a session and 
select a security protocol. The SMB request lists the security protocols 
supported by the client. These protocols include DSS Security, LAN 
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10. 


11. 


Server 4.0 Security, and LAN Server 3.0 Security. (The names of these 
protocols are actually different, but, for clarity, we will call them the 
DSS, LAN Server 4.0, and LAN Server 3.0 protocols.) 


. Because the DSS Server supports the DSS Security protocol and the 


DSS protocol is the best offered by the client, the DSS Server sends an 
SMB response to the client informing the client that the server selects 
the DSS Security protocol. 


The client requests a ticket from the Security Server Authentication 
Service to access the DSS Server. The request contains an encrypted 
PTGT, the identity of the DSS Server, and a timestamp encrypted in the 
AS conversation key. The client obtained the encrypted PTGT and the 
AS key when it performed third-party authentication, as described in the 
previous section. 


The AS decrypts the envelope with the GSSAPI and checks the 
timestamp. If it matches, the client is authentic. The AS creates a ticket 
with the client EPAC and a conversation key for the DSS Server. This 
ticket is encrypted using the client conversation key and sent to the DSS 
Client. 


The client sends an SMB message to the DSS Server containing a 
SecPkg message (an SMB standard). The SecPkg message contains the 
GSSAPIl-encrypted token. 


The DSS Server uses GSSAPI to decrypt the GSSAPIl-encrypted token 
and determines whether the DSS Client is authenticated. 


. Once the client is authenticated, the DSS Server creates a 


GSSAPIl-encrypted reply token containing an encrypted success 
message. 


The DSS Server sends an SMB message to the client containing a 
SecPkg message. The SecPkg message contains the GSSAPI-encrypted 
reply token. 


The DSS Client uses GSSAPI to decrypt the GSSAPI-encrypted reply 
token. If successful, this means that the DSS Server is authentic. 


The client sends an SMB request to the server to establish a secure 
session. All communication between the client and server must be 
through this connection. 


Now that this client is authenticated, the DSS Server continues with 
session setup and will be ready to accept requests from this client. 
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The DSS protocol for establishing mutually authenticated sessions offers the 
following security advantages: 


¢« Both the DSS Client and the DSS Server are able to mutually 
authenticate each other. 


« All security information passed between the DSS Client and DSS Server 
is encrypted in GSSAPI tokens. 


* The DSS Client passes an EPAC to the DSS Server (encrypted in a 
GSSAPI token), so the DSS Server does not need to keep a database on 
users. 


A.5.3 Registry Service in DSS 
This service manages the registry database, which is a single database 
holding all user and group definitions for an entire DSS cell. This registry 
extends the OS/2 LAN Server’s User Account Subsystem (contained within 
the NET.ACC file) by increasing the scope of administration from the 
workgroup-domain-based model to distributed enterprise environments. This 
effectively means that administrators have only one definition to maintain for 
each user in a cell, and users have only one account and one password to 
change, regardless of the number of OS/2 LAN Server domains they need to 
access in the cell. 


As LAN Server domains are migrated to a DSS cell, they are consolidated in 
logical groupings referred to as resource domains. This enables LAN 
Server administrators to continue managing resources local to their domain, 
but the overhead involved in maintaining multiple user IDs and passwords 
for a single user (for cross-domain access) is eliminated. Furthermore, the 
resource domain function allows for users and groups to be “associated” 
with a default resource domain within a cell similar to the logon domain 
concept in LAN Server. These associated accounts are displayed as 
shadowed objects in the resource domain folder with the originals residing 
in the master cell-wide security registry. See Figure 2 on page 16 fora 
diagram of the cell registry tree. 


The cell Security Registry is comprised of the following three object types 
which form the basic units of administration: 


Accounts These are definitions for a network identity or 
principal, such as a user, server or machine (host). In 
addition to the principal name, accounts include other 
related attributes such as the password and 
Universally Unique Identifier (known as a UUID, a 
unique 16-byte internal identifier) to enable the 
account owner to perform a network logon and 
participate in a DCE network. 
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Groups Collections of accounts that are associated by Access 
Control Permissions and identified by a group name. 


Policy Groups These did not exist in LAN Server’s Security 
subsystem, but they are similar to the Groups object 
above. Policy Groups enable a DSS administrator to 
define specific password and account policies, such as 
password lifetime and format for association to a 
group of accounts. 


Based on the resource domain concept, DSS provides the framework for 
administrators to set up a registry database and organize users into groups 
that conform to LAN Server’s domain structure. For each resource domain 
that is configured, five group objects are automatically defined in the 
registry representing the different administrative privileges and operator 
rights migrated from OS/2 LAN Server: 


- ADMINS 

» PRT_OP 

- SRV_OP 

- COMM_OP 
- USERS 


The root of the resource domain namespace in the cell registry is 
/.:/sec/groups/realms, where individual resource domains are defined as 
directories below the root. Resource domains represent branches of the 
realms directory, with each resource domain comprising a fixed structure of 
the five group objects corresponding to the user and administrative roles 
found in LAN Server. 


In DCE, there is a standard set of defined attribute types that can be 
associated with the registry objects (Accounts, Groups and Policy Groups) 
such as account full name, password and cell name. Recognizing that in 
distributed enterprise environments applications may need a varying set of 
registry attributes not present in the fixed collection (schema), DCE supports 
the use of Extended Registry Attributes (ERAs). The DSS product integrates 
the unique security information from LAN Server into the DCE framework by 
defining a set of ERAs to support its own unique attributes. 


Extended Registry Attributes provide a secure way for the administrator to 
associate registry information and specific account attributes to user and 
group definitions. There is a set of ERAs that have been integrated into DSS 
from OS/2 LAN Server, and they comply with the DCE registry attribute 
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definitions in that they have a UUID and a value type (byte, integer, and so 
on). Some of the ERAs from OS/2 LAN Server include: 





Table 9. Extended Registry Attributes Defined by DSS 


Is_home_dir Path of the user’s home directory 





Is_logon_hours 21-byte map indicating which hours of the day a user is allowed to log 
on 





Is_workstations List of requesters from which a user can log on 


logon_asn Data structure representing a user’s logon assignments 


default_realm Name of the default realm for a user 





Is_comment Comment associated with account 





Is_usr_comment User-defined comment associated with account 


Is_encr_passwd User’s DCE password stored in OS/2 LAN Server encrypted format (not 
plain-text readable) 


Is_logon_server Preferred server to validate user logon request 





Is_code_page OS/2 code page for the user 





Is_country_code OS/2 country code for the user 


Is_flags Defines if an account is enabled and if a logon script is defined 


Is_script_path Path of logon script, if defined 





Is_max_storage Maximum number of KB allowed for user’s home directory 





Is_parms Used by applications 


Is_passwd_hist Used to record password history list 


Is_priv_app Lists a user’s private application definitions 








The DSS Security Service allows the administrator to create new schema 
entries or ERAs for association with their user or group definitions. One 
example would be an employee serial number that could also be defined as 
“unique” to ensure that no duplicate serial numbers get used. Also, an ERA 
can be defined with a “trigger” type which initiates RPC calls to specified 
servers when the attribute is queried. The registry schema/attributes can 
be manipulated using the DCECP command line interface or from the DSS 
GUI. 





A.6 Distributed Time Service 


Keeping the clocks on different hosts synchronized is a difficult task as the 
hardware clocks do not run at the same rates. This presents problems for 
distributed applications that depend on the ordering of events that happen 
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during their execution. For example, let’s say that a programmer is 
compiling some code on a workstation, and some files are also located on a 
server. If the workstation and the server don’t have their time synchronized, 
it is possible that the compiler may not process a file because the date is 
older than an existing one on the server. In reality, the file is newer, but the 
clock on the workstation is slow. As a result, the compiled code will not 
reflect the latest source code changes. 


The DCE Distributed Time Service provides standard software mechanisms 
to synchronize clocks on the different hosts in a distributed environment. It 
also provides a way of keeping a host’s time close to the absolute time. 


Note: OS/2 uses the system clock and does not keep track of the time 
differential between Universal Time Coordinated (UTC) and the local 
time. Because of this, special steps must be taken during switching 
to and from Daylight Savings Time. See 5.6.3, “Time Service” on 
page 155 for more information. 


The Distributed Time Service is optional. It is not a required core service for 
the DCE cell. However, if DTS is not implemented, the administrator must 
use some other means of keeping clocks synchronized for all the systems in 
the cell. 


The Distributed Time Service has several components. They are: 
* Local Time Server 
* Global Time Server 


¢ Courier and Backup Courier Time Server 


A.6.1 Local Time Server 
The Local Time Server is responsible for answering time queries from time 
clerks on the LAN. Local Time Servers also query each other to maintain 
synchronization on the LAN. If a time clerk cannot contact the required 
number of Local Time Servers (as specified by the minservers attribute), it 
must contact Global Time Servers through a CDS lookup. 


It is recommended that there are at least three Local Time Servers per LAN. 
This ensures that the time on this LAN is synchronized, but what about the 
other LANs and the rest of the cell? This is where Global Time Servers and 
Courier Time Servers are used. 


A.6.2 Global Time Server 
A Global Time Server (GTS) advertises itself in the Cell Directory Service 
namespace so that all systems can find it easily. A GTS participates in the 
local LAN in the same way that Local Time Servers do, but it has an 
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additional responsibility. It also gives its time to a Courier Time Server, 
which is located in a different LAN. 


A.6.3 Courier Roles 


Local and Global Time Servers can also have a courier role—they can be 
Couriers, Backup Couriers or non-Couriers. The Courier behaves similar to 
other Local Time Servers, participating in the time synchronization process. 
However, the Courier does not look at it’s own clock. It requests the time 
from a Global Time Server located in another LAN or in another part of the 
cell. Because the time is imported from another part of the network, this 
enables many remote LAN segments in all parts of the cell to have a very 
closely synchronized time value. 


The Backup Courier role provides support in the event that the primary 
Courier for that LAN is not available. The Backup Couriers will negotiate to 
elect a new Courier and thus maintain the proper time synchronization with 
the Global Time Servers. Note that even if a Courier Time Server is not 
defined, Local Time Servers and clerks will try to contact a Global Time 
Server if they cannot contact the minimum number of servers from the local 
segment. 


The default for Time Servers is the non-Courier role. As long as enough 
Local Time Servers can be contacted, they will not contact a Global Time 
Server. 


In a large or distributed network, Local Time Servers, Global Time Servers 
and Courier Time Servers make the process of time synchronization 
function automatically and accurately. 


For additional information on Time Server architecture and administration, 
refer to the online DCE Administrators Reference or to the publication titled 
Understanding OSF DCE Version 1.1 for AlX and OS/2, SG24-4616. 





A.7 Distributed File Service (DFS) 


The Distributed File Service is not really a core component of DCE but an 
application that is integrated with and uses the other DCE services. As its 
name implies, DFS is a file system implementation which is intended for the 
distributed systems environment. DFS has the benefits of location 
transparency, performance, security, availability, and interoperability with 
other standards, like NFS. 


Note: The Directory and Security Server for OS/2 Warp does not include an 
implementation of the DFS Server, but it does contain the DFS Client. 
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Appendix B. Sample Export Files 


This section contains the sample export files that were produced from an 
actual manual migration. Some of the sample export files have been 
truncated because even a small environment can produce very large export 


files. 


B.1 Aliases File 


File name: ALDC1.EXP. 





# SERVER INFORMATION 


Database entity: SERVER 

DC Server name: ITSODSS1 
Additional server name: ADDDSS1 
EOR 

# ALIAS DEFINITIONS 

Database entity: ALIAS 
Short alias name: CHAMPION 
Remark: E drive in ITSODSS1 
Alias type: File 
Server name: ITSODSS1 
Server path to directory: Es\ 

Share mode: Startup 
Maximum number of users: Unlimited 
EOR 

Database entity: ALIAS 
Short alias name: EURO96 





Remark: D drive in ITSODSS1 
Alias type: File 

Server name: ADDDSS1 

Server path to directory: E:\OPEN 

Share mode: Startup 

Maximum number of users: Unlimited 

EOR 

Database entity: ALIAS 

Short alias name: HIGHLAND 

Remark: D drive in ITSODSS1 
Alias type: File 

Server name: ITSODSS1 

Server path to directory: D:\ 

Share mode: Startup 

Maximum number of users: Unlimited 


EOR 





Figure 49. Example of Aliases Export File 





B.2 Public Applications File 
File name: APPDC1.EXP. 


© Copyright IBM Corp. 1997 
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# APPLICATION INFORMATION 
Database entity: 
App name: 
Remark: 

Command: 

Command parm: 
App alias: 

App drive: 

App path: 

App wrk alias: 
App wrk drive: 
App wrk path: 
App prompt: 

App interface: 
App apptype: 

EOR 





PUBLIC APPLICATION 
PSPM2 

Task Monitor for 0S/2 
pspm2.exe 


CHAMPION 
0 





Figure 50. Example of Public Application Export File 





B.3 User and Group Definition File 
File name: USRDC1.EXP. 


# GROUP INFORMATION 
Database entity: 
Group name: 

Collision resolution: 
Comment: 

Imported: 

EOR 

Database entity: 
Group name: 

Collision resolution: 
Comment : 

Imported: 

EOR 

Database entity: 
Group name: 

Collision resolution: 
Comment: 


Imported: 

EOR 

Database entity: 
Group name: 

Collision resolution: 
Comment : 

Imported: 

EOR 


GROUP 
GROUPID 


Default Group ID 
NO 


GROUP 
DSS1 
NO 


GROUP 
DSS2 


Group created on Wed Jun 12 18:01:27 1996 
NO 

GROUP 

LOCAL 


NO 


Figure 51 (Part 1 of 9). Example of User and Group Definition Export File 
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Inside DSS for OS/2 Warp 


# USER INFORMATION 
Database entity: 
User ID: 
Collision resolution: 
Definition: 
Full name: 
Comment: 
User comment: 
User privilege: 
Operator privileges: 
User flags: 
User parms: 
Home directory: 
Maximum disk space (KB): 
Logon script: 
Workstations allowed: 
Logon server: 
Logon hours: 
Country code: 
Code page: 
Account expires: 
Encrypted password: 
Password expires: 
EOL 
Group memberships: 
SERVERS 
USERS 
EOL 
EOR 
Database entity: 
User ID: 
Collision resolution: 
Definition: 
Full name: 
Comment: 
User comment: 
User privilege: 
Operator privileges: 
User flags: 
User parms: 
Home directory: 
Maximum disk space (KB): 
Logon script: 
Workstations allowed: 
Logon server: 
Logon hours: 
Country code: 
Code page: 
Account expires: 
Encrypted password: 
Password expires: 
EOL 


Figure 51 (Part 2 of 9). 


USER 
ADDDSS1 


Add’ 1 Server for ITSODOM1 
System ID - Server 
System ID - Server 

USERS 

None 

23 


FFFFFFFFFFFFFFFFFFFFFFFFFERFFERFFFPFE FFF F 
0 

0 

0 

29B3A15FA90F634B312F32AD3F 

NO 


USER 
ITSO02 


USERS 
None 
01 


\\ADDDSS1\D$\HOME\ ITSO02 
Unlimited 


\\* 
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 
0 

0 

Never 

CF6DFA3298427(62E2963D59090D0F5B 

NO 


Example of User and Group Definition Export File 


Appendix B. Sample Export Files 


195 


Group memberships: 
DSS2 
USERS 
EOL 
Logon assignment list: 
Alias: CHAMPION 
Alias: CHAMPION 
EOL 
Application assignment list: 
AppID: PSPM 
EOL 
EOR 
Database entity: 
User ID: 
Collision resolution: 
Definition: 
Full name: 
Comment: 
User comment: 
User privilege: 
Operator privileges: 
User flags: 
User parms: 
Home directory: 
Maximum disk space (KB): 
Logon script: 
Workstations allowed: 
Logon server: 
Logon hours: 
Country code: 
Code page: 
Account expires: 
Encrypted password: 
Password expires: 
EOL 
Group memberships: 
DSS2 
USERS 
EOL 
Logon assignment list: 








Alias: CHAMPION Type: 
Alias: CHAMPION Type: 

EOL 

Application assignment list: 
AppID: PSPM 

EOL 

EOR 


Type: 
Type: 


File Device: * 

File Device: * 

Type: 2 

USER 

ITSO03 

USERS 

None 

01 

\\ADDDSS1\D$\HOME\ 1TS003 
Unlimited 

We 
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 
0 

0 

Never 
685291D89386D542275E25B5D3251C24 
NO 

File Device: * 

File Device: * 

Type: 2 


Figure 51 (Part 3 of 9). Example of User and Group Definition Export File 
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Inside DSS for OS/2 Warp 


Database entity: 
User ID: 
Collision resolution: 
Definition: 
Full name: 
Comment: 
User comment: 
User privilege: 
Operator privileges: 
User flags: 
User parms: 
Home directory: 
Maximum disk space (KB): 
Logon script: 
Workstations allowed: 
Logon server: 
Logon hours: 
Country code: 
Code page: 
Account expires: 
Encrypted password: 
Password expires: 
EOL 
Group memberships: 
DSS1 
DSS2 
USERS 
EOL 
Logon assignment list: 


Alias: CHAMPION Type: 
Alias: CHAMPION Type: 
Alias: OPEN Type: 


EOL 

Application assignment list: 
AppID: PSPM 

EOL 

EOR 


USER 
ITSO01 


USERS 
None 
01 


\\ADDDSS1\D$\HOME\ITSOO1 
Unlimited 


AN 
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 
0 

0 

Never 

81C6DA7CD357C7B510B73D1B83BE7652 

NO 


File Device: * 
File Device: * 
File Device: * 


Type: 2 


Figure 51 (Part 4 of 9). Example of User and Group Definition Export File 
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Database entity: 
User ID: 
Collision resolution: 
Definition: 
Full name: 
Comment: 
User comment: 
User privilege: 
Operator privileges: 
User flags: 
User parms: 
Home directory: 
Maximum disk space (KB): 
Logon script: 
Workstations allowed: 
Logon server: 
Logon hours: 
Country code: 
Code page: 
Account expires: 
Encrypted password: 
Password expires: 
EOL 
Group memberships: 
GROUPID 
ADMINS 
EOL 
Application assignment list: 
AppID: PSPM 
EOL 
EOR 
Database entity: 
User ID: 
Collision resolution: 
Definition: 
Full name: 
Comment: 
User comment: 
User privilege: 
Operator privileges: 
User flags: 


Figure 51 (Part 5 of 9). 





USER 
USERID 


Default User ID 
ADMINS 

None 

01 


Unlimited 


FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 
0 

437 

Never 

83A409450E7D636B337F11E52B83385F 

NO 


Type: 2 


USER 
CLIENTO4 


USERS 
None 
01 


Example of User and Group Definition Export File 
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User parms: 
Home directory: 
Maximum disk space (KB): 
Logon script: 
Workstations allowed: 
Logon server: 
Logon hours: 
Country code: 
Code page: 
Account expires: 
Encrypted password: 
Password expires: 
EOL 
Group memberships: 
DSS1 
USERS 
EOL 
Logon assignment list: 


EOL 
Application assignment list: 
AppID: PSPM 
EOL 
EOR 
Database entity: 
User ID: 
Collision resolution: 
Definition: 
Full name: 
Comment: 
User comment: 
User privilege: 
Operator privileges: 
User flags: 
User parms: 
Home directory: 
Maximum disk space (KB): 
Logon script: 
Workstations allowed: 
Logon server: 
Logon hours: 
Country code: 
Code page: 
Account expires: 
Encrypted password: 
Password expires: 
EOL 





Alias: DSS Type: 
Alias: OPEN Type: 


\\ADDDSS1\D$\HOME\CLIENTO4 
Unlimited 


\\* 
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 
0 

0 

Never 

72C215F73096EBA1B87 1509C3C4E3 

NO 


File Device: * 
File Device: * 


Type: 2 


USER 
CLIENTO5 


USERS 
None 
01 


\\ADDDSS1\D$\HOME\CLIENTO5 
Unlimited 


is 
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 
0 

0 

Never 

CBF44F4D0EC6945530721858E933B6DC 

NO 


Figure 51 (Part 6 of 9). Example of User and Group Definition Export File 
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Group memberships: 


DSS1 
USERS 
EOL 
Logon assignment list: 
Alias: DSS Type: 
Alias: OPEN Type: 
EOL 


Application assignment list: 
AppID: PSPM 
EOL 
EOR 
Database entity: 
User ID: 
Collision resolution: 
Definition: 
Full name: 
Comment: 
User comment: 
User privilege: 
Operator privileges: 
User flags: 
User parms: 
Home directory: 
Maximum disk space (KB): 
Logon script: 
Workstations allowed: 
Logon server: 
Logon hours: 
Country code: 
Code page: 
Account expires: 
Encrypted password: 
Password expires: 
EOL 
Group memberships: 
DSS1 
USERS 
EOL 
Logon assignment list: 
Alias: DSS 
Alias: OPEN 
EOL 
Application assignment list: 
AppID: PSPM 
EOL 
EOR 








Type: 
Type: 


File Device: * 

File Device: * 

Type: 2 

USER 

CLIENTO2 

USERS 

None 

01 

\\ADDDSS1\D$\HOME\CLIENTO2 
Unlimited 

\\* 
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 
0 

0 

Never 
2EFB98863CC5DC8433734CAAB32E84A6 
NO 

File Device: * 

File Device: * 

Type: 2 


Figure 51 (Part 7 of 9). Example of User and Group Definition Export File 
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Inside DSS for OS/2 Warp 


Database entity: 
User ID: 
Collision resolution: 
Definition: 
Full name: 
Comment: 
User comment: 
User privilege: 
Operator privileges: 
User flags: 
User parms: 
Home directory: 
Maximum disk space (KB): 
Logon script: 
Workstations allowed: 
Logon server: 
Logon hours: 
Country code: 
Code page: 
Account expires: 
Encrypted password: 
Password expires: 
EOL 
Group memberships: 
DSS1 
DSS2 
USERS 
EOL 
Logon assignment list: 


Alias: CHAMPION Type: 
Alias: DSS Type: 
Alias: OPEN Type: 


EOL 

Application assignment list: 
AppID: PSPM 

EOL 

EOR 


USER 
CLIENTO3 


USERS 
None 
01 


\\ADDDSS1\D$\HOME\CLIENTO3 
Unlimited 


AN 
FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF 
0 

0 

Never 

D2204DC1546018C1674324EFCED24 

NO 


File Device: * 
File Device: * 
File Device: * 


Type: 2 


Figure 51 (Part 8 of 9). Example of User and Group Definition Export File 
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Database entity: 
User ID: 
Collision resolution: 
Definition: 
Full name: 
Comment: 
User comment: 
User privilege: 
Operator privileges: 
User flags: 
User parms: 
Home directory: 
Maximum disk space (KB): 
Logon script: 
Workstations allowed: 
Logon server: 
Logon hours: 
Country code: 
Code page: 
Account expires: 
Encrypted password: 
Password expires: 
EOL 
Group memberships: 
DSS1 
USERS 
EOL 
Logon assignment list: 


EOL 
Application assignment list: 
AppID: PSPM 

EOL 
EOR 





Alias: DSS Type: 
Alias: OPEN Type: 


USER 
CLIENTO1 


USERS 
None 
01 


\\ADDDSS1\D$\HOME\CLIENTO1 
Unlimited 


FFFFFFFFFFFFFFFF FRPP FRPP FRFF FRPP PEPE FEFFFE 


0 

0 

Never 
7101291E728F9218CA2C7CCCE780868A 
NO 

File Device: * 

File Device: * 

Type: 2 


Figure 51 (Part 9 of 9). Example of User and Group Definition Export File 


B.4 ACL Export File of Domain Controller 


File name: !TSO_DC1.EXP. We have truncated a very long file. 
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# ACCESS CONTROL INFORMATION 


[DRIVES] 
Resource: 
Audit: 
ACLlist: 
EOR 
Resource: 
Audit: 
ACLlist: 
EOR 
Resource: 
Audit: 
ACLlist: 
EOR 
Resource: 
Audit: 
ACLlist: 
EOR 
Resource: 
Audit: 
ACLlist: 
EOR 
Resource: 
Audit: 
ACLlist: 
EOR 
[DIRECTORIES] 
Resource: 
IMPLICIT: 
DSS_DRIVE: 
EOR 
Resource: 
Audit: 
ACLlist: 
User: 
Access: 
Group: 
Access: 
Group: 
Access: 
EOR 
Resource: 
Audit: 
ACLlist: 
User: 
Access: 
Group: 
Access: 
Group: 
Access: 
EOR 








A: 
0000 


Br 
0000 


C: 
0000 


D: 
0000 


Ee 
0000 


Fs 
0000 


C:\ 


0000 


USERID 
007f 
DSS2 
8049 
DSS1 
807f 


0000 


USERID 
007f 
DSS2 
8049 
DSS1 
807f 





Figure 52 (Part 1 of 4). Example of ACL Export File of Domain Controller (truncated) 
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Resource: C:\0S2 
LICIT: 

SS DRIVE: 
0 

e 


wza7mo: 


urce: C:\0S2\DLL 
LICIT: 
DRIVE: 


fo} 


w7mo: 
fo) 


urce: C:\0S2\DLL\ IBMNULL 
LICIT: 
DRIVE: 


oO 


wz7mo: 
co) 


urce: C:\0S2\HELP 
LICIT: 
DRIVE: 


Pe ase a 
Fe eS pet po ie on i eee 


urce: C:\0S2\HELP\GLOSS 
LICIT: 
DRIVE: 


fo} 


wz7mo: 
co) 


urce: C:\0S2\HELP\TUTORIAL 
LICIT: 
DRIVE: 


o 








w7mo: 
oo 
° 


source: C:\0S2\ INSTALL 
ICIT: 
DRIVE: 


mo) 
c 


wr7mo: 
on 
Dan 


esource: C:\0S2\ INSTALL\VGA 
LICIT: 
DRIVE: 


zw7mo: 
Ton 


n 


urce: C:\0S2\ INSTALL\BOOTDISK 
LICIT: 
DRIVE: 


wz7mo: 
Ton 
° 


urce: C:\0S2\ INSTALL\WARPSRV .BAK 
LICIT: 
DRIVE: 


fo} 





wz7mo: 
oo 


urce: C:\0S2\ INSTALL\WSCONFIG 
LICIT: 
DRIVE: 


pr7mo: 
Ton 
° 


urce: C:\0S2\SYSTEM 
LICIT: 
DRIVE: 


o 








ource: C:\0S2\SYSTEM\ TRACE 
IMPLICIT: 
DSS DRIVE: 





























Figure 52 (Part 2 of 4). Example of ACL Export File of Domain Controller (truncated) 
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Resource: C:\0S2\SYSTEM\EPW 
LICIT: 


SS_DRIVE: 

EO 

esource: C:\0S2\BO0K 
LICIT: 

DRIVE: 


i=) 
n 
fo} 


zm 
oo 


urce: C:\0S2\MDOS 
LICIT: 
DRIVE: 


fo} 





ource: C:\0S2\MDOS\WINOS2 




















DRIVE: 





Resource: C:\IBMI18 
PLICIT: 
SS_DRIVE: 
EOR 
e 


=_ 


ource: C:\IBMI18N\DLL 
LICIT: 
DSS DRIVE: 


Ss 
P 
EOR 
Ss 
P 








R 
Resource: C:\ IBMI18N\LOCALE 
LICIT: 

DSS_DRIVE: 


EOR 


























Figure 52 (Part 3 of 4). Example of ACL Export File of Domain Controller (truncated) 
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Audit: 
ACLlist: 
User: 


Group: 
Group: 


EOR 
[FILES] 


Audit: 
ACLlist: 
Group: 
EOR 
Audit: 
ACLlist: 
Group: 
Group: 
EOR 
Audit: 
ACLlist: 
Group: 
EOR 
Audit: 
ACLlist: 


Group: 


EOR 





Resource: 
EXPLICIT: 


Access: 


Access: 


Access: 


Resource: 


Access: 


Resource: 


Access: 


Access: 


Resource: 


Access: 


Resource: 


Access: 





E:\migutils 


0000 


USERID 
007f 
DSS2 
8049 
DSS1 
807f 


\PIPE 
0000 


USERS 
8007 


\PIPE\ IBMLAN\SERVER. RNS 
0f00 


USERS 
8003 
GUESTS 
8003 


\PRINT 
0000 


USERS 
8004 


\COMM 
0000 


USERS 
8007 





Figure 52 (Part 4 of 4). Example of ACL Export File of Domain Controller (truncated) 





B.5 ACL Export File of Additional Server 


File name: ADDDSS1.EXP. 
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# ACCESS CONTROL INFORMATION 


[DRIVES] 
Resource: 
Audit: 
ACLlist: 
EOR 
Resource: 
Audit: 
ACLlist: 
EOR 
Resource: 
Audit: 
ACLlist: 
EOR 
Resource: 
Audit: 
ACLlist: 
EOR 
Resource: 
Audit: 
ACLlist: 
EOR 
Resource: 
Audit: 
ACLlist: 
EOR 
[DIRECTORIES] 
Resource: 
IMPLICIT: 
DSS_DRIVE: 
EOR 
Resource: 
IMPLICIT: 
DSS_DRIVE: 
EOR 
Resource: 
Audit: 
ACLlist: 
User: 
Access: 
EOR 
Resource: 
IMPLICIT: 
DSS_DRIVE: 
EOR 
Resource: 
IMPLICIT: 
DSS_DRIVE: 
EOR 


























A: 
0000 


B: 
0000 


C: 
0000 


D: 
0000 


Es 
0000 


Fe 
0000 


C:\ 


D:\ 


0000 


USERID 
007f 


C:\BOOKS 


C:\Desktop 


Figure 53 (Part 1 of 4). Example of ACL Export File of Additional Server (truncated) 
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Resource: C:\Desktop\IBM Internet*Connection for 0S!2 

IMPLICIT: 

DSS_DRIVE: 

EOR 

Resource: C:\Desktop\IBM Internet*Connection for 0S!2 
\Application*Temp]ates 

IMPLICIT: 

DSS_DRIVE: 

EOR 

Resource: C:\Desktop\IBM Internet*Connection for 0S!2 
\IBM Internet*Customer Services 

IMPLICIT: 

DSS_DRIVE: 

EOR 

Resource: C:\Desktop\IBM Internet*Connection for 0S!2 
\Internet*Utilities 

IMPLICIT: 

DSS_DRIVE: 

EOR 

Resource: C:\Desktop\IBM Internet*Connection for 0S!2 
\Ultimedia*Mail!2 ’ Lite’ 

IMPLICIT: 

DSS_DRIVE: 

EOR 

Resource: C:\Desktop\IBM Internet*Connection for 0S!2 

\Ultimedia*Mail!2 ’ Lite’ \Information 
LICIT: 
DRIVE: 


z7Amovo: 
non 
oO 


urce: C:\Desktop\Information 
LICIT: 
DRIVE: 


7Amovo: 
=) 
fo} 


urce: C:\Desktop\Information\IBM Internet*Connection for 0S!2 
LICIT: 
DRIVE: 





fo} 


urce: C:\Desktop\Information\LAN Services*File and Print 
LICIT: 
DRIVE: 





z7Amovo: 
i=) 
fo} 


urce: C:\Desktop\Information\0S!2 Base*Operating System 
LICIT: 
DRIVE: 





Pog: 2O3! 
uN mie eS Pie eS ee Ee Ae ee DnV 


e 


fo} 


urce: C:\Desktop\Information\TCP! IP 
IMPLICIT: 
DSS_DRIVE: 
EOR 


Figure 53 (Part 2 of 4). Example of ACL Export File of Additional Server (truncated) 
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Resource: 
IMPLICIT: 


EOR 
Resource: 
IMPLICIT: 


EOR 
Resource: 
IMPLICIT: 


EOR 
Resource: 
IMPLICIT: 


EOR 
Resource: 
IMPLICIT: 


EOR 
Resource: 
IMPLICIT: 


EOR 
Resource: 
IMPLICIT: 














DSS_DRIVE: 


EOR 


Resource: 
EXPLICIT: 
Audit: 
ACLlist: 
User: 
Access: 
EOR 
Resource: 
EXPLICIT: 
Audit: 
ACLlist: 
User: 
Access: 
EOR 


DSS_DRIVE: 


DSS_DRIVE: 


DSS_DRIVE: 


DSS_DRIVE: 


DSS_DRIVE: 


DSS_DRIVE: 


C:\Desktop\LAN Services*File and Print 


C:\Desktop\0S!2 CodeServer*Distributor 


C:\Desktop\0S!2 CodeServer“Distributor\Server 


C:\Desktop\0S!2 System 


C:\Desktop\0S!2 System\Command Prompts 


C:\Desktop\0S!2 System\DOS Programs 


C:\Desktop\0S!2 System\Drives 


E: \open\SHAREA\SRV 
0000 


USERID 
007f 


E:\tools 
0000 


USERID 
007f 


Figure 53 (Part 3 of 4). Example of ACL Export File of Additional Server (truncated) 
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[FILES] 


Resource: \PIPE 
Audit: 0000 
ACLlist: 
Group: USERS 
Access: 8007 
EOR 
Resource: \PIPE\ IBMLAN\SERVER. RNS 
Audit: 0f00 
ACLlist: 
Group: USERS 
Access: 8003 
Group: GUESTS 
Access: 8003 
EOR 
Resource: \PRINT 
Audit: 0000 
ACLlist: 
Group: USERS 
Access: 8004 
EOR 
Resource: \COMM 
Audit: 0000 
ACLlist: 
Group: USERS 
Access: 8007 
EOR 





Figure 53 (Part 4 of 4). Example of ACL Export File of Additional Server (truncated) 
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Appendix C. Supported Network Adapters 


Table 10 lists the adapters that are supported for operation with the 
Directory and Security Server for OS/2 Warp. Some adapters are supported, 
but a driver is not included with the Directory and Security Server for OS/2 
Warp product. Some of these drivers may be available on the OS/2 
Supplemental NIC Driver Diskette. They are signified with an asterisk (*) in 
the “Driver Included?’ column. This NIC Driver diskette can be downloaded 
from the following external IBM Web site: 


http://www. austin. ibm.com/pspinfo/nic.htm 


If the driver is not included in the product and not included on the OS/2 
Supplemental NIC Driver Diskette, then contact the manufacturer of the 
adapter card to obtain the driver. Check the company’s bulletin board or 
FTP site. 


Table 10 (Page 1 of 6). Supported Network Adapter Cards 


Network Adapter Name Driver Included? 





3Com EtherLink II (3C503) Yes 





3Com EtherLink II-16 (30503-16) 


3Com EtherLink II-16-TP (3C503-16-TP) 


3Com EtherLink 16 (3C507) 
3Com EtherLink 16-TP (3C507-TP) 








3Com EtherLink/MC (3C523B) 


3Com EtherLink/MC-TP (3C523B-TP) 


3Com EtherLink MC-32 (3C527B) 
3Com EtherLink III (80509) 








3Com EtherLink III (83C509B) 
3Com EtherLink IIl-Combo (3C509B-COMBO) 
3Com EtherLink III-TP (3C509-TP) 

3Com EtherLink III-TP (8C509B-TP) 

3Com EtherLink III-TPO (83C509B-TPO) 
3Com EtherLink III-EISA (30579) 

3Com EtherLink III-EISA-TP (3C579-TP) 


3Com EtherLink III-MCA (30529) 
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Table 10 (Page 2 of 6). Supported Network Adapter Cards 





Network Adapter Name 


Driver Included? 




















3Com EtherLink III-MCA-TP (3C529-TP) Yes 
3Com EtherLink III-PCMCIA-TP (3C589-TP) [client only] No* 
3Com EtherLink III-PCMCIA-Combo (3C589B-Combo) [client only] No* 
3Com EtherLink II] LAN PC Card Combo (3C589C-COMBO) [client only] No* 
3Com EtherLink II| LAN PC Card 10BASE-T (3C589C-TP) [client only] No* 
3Com EtherLink II| LAN + Modem PC Card (3C562-TP) (LAN ONLY) No* 
[client only] 

3Com EtherLink IIl PC! 10BASE-T Network Adapter (3C590-TPO) No* 
3Com Fast EtherLink PCI 10/100 BASE-T Network Adapter (3C595-TX) No* 
3Com TokenLink III (30619) No* 
3Com TokenLink III EISA (30679) No* 
3Com TokenLink III MCA (30629) Yes 
3Com TokenLink III 16/4 PC Card (3C689) [client only] No* 


























Accton EtherCombo-16 (EN1650) 
Accton EtherPair-16 (EN1651) No 
Accton EtherCoax-16 (EN1652) No 
Accton EtherCombo-32 (EN1200) No 
Accton EtherCombo-TX PCI Adapter (EN1207) No* 
AMD PCnet-ISA II Ethernet Adapter No* 
AMD PCnet-PCI Ethernet Adapter No* 
Allied Telesyn Ethernet Adapter Card ISA (AT-1500BT-PLUS) No 
Artisoft NodeRunner/SI 2000/C Yes 
Artisoft NodeRunner/SI 2000/T Yes 
Artisoft NodeRunner/SI 2000/A Yes 
Artisoft LANTastic NodeRunner 2000/C Yes 
Artisoft LANTastic NodeRunner 2000/T Yes 
Artisoft LANTastic NodeRunner 2000/A Yes 
Asante EtherPaC 2000+3 No 
Asante EtherPaC 2000+N No 


Asante EtherPaC 2000+T 
Cabletron Ethernet DNI Adapter (E2112) 








Cabletron Ethernet DNI Adapter (E2119) 
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Table 10 (Page 3 of 6). Supported Network Adapter Cards 





Network Adapter Name Driver Included? 
Cabletron Ethernet DNI Adapter (E3119) 

CeLAN FlexLINK - EPClplus (9910EPCI-B) 

Cogent eMASTER+ EM960 PCI Ethernet Adapter (EM960C) 
Compag NetFlex-2 ENET-TR Controller 

DCA ClassicBlue MC 4/16 Token-Ring Adapter 
DCA IRMAtrac EISA 

D-Link Ethernet Interface Card for the PC XT/AT (DE-220C) 
D-Link Ethernet Interface Card for the PC XT/AT (DE-220CAT) 




















D-Link Ethernet Interface Card for the PC XT/AT (DE-220CT) 
D-Link Plug and Play Ethernet ISA (DE-220PCT) 
D-Link Ethernet Card for EISA bus PC (DE-400) 
D-Link Ethernet PCI (DE-530CT) 








Hewlett-Packard PCLAN Adapter/16 PLUS (27252A) 


IBM LAN Adapter for Ethernet (48G7169) 
IBM LAN Adapter for Ethernet CX (60G0615) 








IBM LAN Adapter for Ethernet TP (60G0605) 
IBM Ethernet Network Adapter 10Base2 66G0943 (JAPAN ONLY) 
IBM PCI Ethernet Adapter (13H9237) 

IBM 100/10 PCI Ethernet Adapter (25H4374) 

IBM Credit Card Adapter for Ethernet 10BT (0933290) [client only] 
IBM Credit Card Adapter II for Ethernet 10B2 (0934330) [client only] 
IBM Credit Card Adapter II for Ethernet 10BT (0934331) [client only] 
IBM Adapter/A for Ethernet Twisted-Pair Networks (6451136) 

IBM Ethernet Network Adapter/A 10Base2/5 35G2793 (JAPAN ONLY) 


























IBM Ethernet Network Adapter 10Base5/T 35G2806 (JAPAN ONLY) 
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Table 10 (Page 4 of 6). Supported Network Adapter Cards 





Network Adapter Name 


Driver Included? 



































IBM LAN Adapter/A for Ethernet (48G7171) Yes 
IBM Ethernet Quad-BT PeerMaster Server Adapter (06H5184) No 
IBM Ethernet Quad-B2 PeerMaster Server Adapters (06H6041) No 
IBM Token-Ring Network 16/4 Adapter Yes 
IBM Token-Ring Network 16/4 ISA-16 Adapter (73G2032) 
IBM Token-Ring Network 16/4 Adapter II Yes 
IBM Auto 16/4 Token-Ring ISA Adapter (92G7632) Yes 
IBM Auto LANStreamer PCI Adapter (04H8095) Yes 
IBM Token-Ring 16/4 Credit Card Adapter II (0933931) [client only] Yes 
IBM PCMCIA Token-Ring Adapter (04H6922) [client only] Yes 
IBM Token-Ring Network 16/4 Adapter/A (16F1133) Yes 
IBM Token-Ring Network 16/4 Adapter/A (74F9410) Yes 
IBM Auto 16/4 Token-Ring MC Adapter (92G7682) Yes 
Intel EtherExpress 16C (PCLA8100) Yes 
Intel EtherExpress FlashC (PCLA8105) Yes 
Intel EtherExpress 16 (PCLA8110) Yes 
Intel EtherExpress Flash (PCLA8115) Yes 
Intel EtherExpress 16TP (PCLA8120) Yes 
Intel EtherExpress FlashTP (PCLA8125) Yes 
Intel EtherExpress PRO/10 LAN Adapter (PCLA8200A) No* 
Intel EtherExpress PRO/100 LAN Adapter EISA (EILA8225) No* 
Intel EtherExpress MCA (MCLA8110) Yes 
Intel EtherExpress MCATP (MCLA8120) Yes 





Intel 


EtherExpress PRO/100 PCI (PILA8465) 
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Intel TokenExpress ISA/16S (PCLA8130A) 

Intel TokenExpress 16/4 LAN Adapter for EISA (EILA8235) Yes 
Intel TokenExpress EISA/32 LAN Adapter (EILA8245) Yes 
Kingston EtherRx PCI Ethernet Adapter (KNE40BT) No* 
Kingston EtherRx LC ISA Combo (KNE2021LC) No* 
Kingston EtherRx LC ISA TP (KNE2000TLC) No 
Kingston Ethernet PC Card [client only] No 
Kingston TokenRx ISA 16/4 Token-Ring Adapter Yes 





Table 10 (Page 5 of 6). Supported Network Adapter Cards 





Network Adapter Name 


Driver Included? 


Kingston TokenRx MC 16/4 Token-Ring Adapter Yes 
No 


Kingston TokenRx PCMCIA 16/4 Adapter (KTR-PCM16/4) [client only] 





LinkSys Combo Ether16 LAN Card (LNE2000) 


No 





LinkSys Combo EtherPCI LAN Card (LNEPCI) 
LinkSys Combo EtherFast 10/100Base-TX LAN Card (LNE100TX) 
Madge Smart 16/4 AT PLUS Ringnode (52-03) 


No* 
o* 
es 


N 
Y 





Madge Smart 16/4 ISA Client Plus Ringnode (22-01) [client only] 


Yes 





Madge Smart 16/4 ISA Client PnP Ringnode (22-04) 


Yes 
Madge Smart 16/4 EISA Ringnode (52-08) Yes 
Yes 


Madge Smart 16/4 MC Ringnode (54-08) 





Madge Smart 16/4 MC32 Ringnode (54-09) 


Yes 





Madge Smart 16/4 PCMCIA Ringnode (20-00) [client only] 


N 


o* 
Madge Smart 16/4 PCI Ringnode (51-02) No* 
Yes 


Madge Straight Blue 16/4 ISA (62-01) 





Madge Straight Blue ISA Plus Blue Box (62-02) 


Yes 





Madge Straight Blue MC Blue Box (64-01) 
Madge Blue+ 16/4 ISA Adapter (62-03) 
Microdyne Novell PCI Ethernet Adapter (NE5500) 


Yes 
Yes 
No* 





Microdyne Novell PCI Fast Ethernet Adapter (NE10/100) 


No 





Olicom USA, Inc. Ethernet PCI 10/100 Adapter (OC-2315) 
Olicom USA, Inc. ISA 16/4 Adapter (OC-3117) 
Olicom USA, Inc. ISA 16/4 Adapter (OC-3118) 


No 


No* 





Olicom USA, Inc. EISA 16/4 Adapter (OC-3133) 


No* 





Olicom USA, Inc. EISA/32 Adapter (OC-3135) 


N 


o* 
Olicom USA, Inc. MCA 16/4 Adapter (OC-3129) No* 
No* 


Olicom USA, Inc. PCI 16/4 Adapter (OC-3136) 





Olicom USA, Inc. Pocket Token-Ring Adapter (OC-3210) [client only] 


No 





Olicom USA, Inc. Token-Ring PCMCIA Card (OC-3220) [client only] 
Proteon ProNET/E PCI Ethernet (p1670-EA) 
Proteon ProNET - 4/16 Plus (p1892plus) 


No* 
No* 
No 





Proteon ProNET - 4/16 Plus (p1990plus) 


No 





Racal InterLan AT TP (163-3118) 








No 
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Table 10 (Page 6 of 6). Supported Network Adapter Cards 











Network Adapter Name Driver Included? 

Racal InterLan ES3210 (132-3169) 
Racal InterLan ES3210-TP (163-3160) No 

Racal InterLan MCA (163-3142) No 

Racal InterLan MCA-TP (163-3143) No 

Racal InterLan PCI T2 (163-3215) No* 

Silcom TR Direct/Blue ISA Yes 





SMC EtherPower 10BASE-T PCI Ethernet Adapter (8432T) 





SMC EtherPower Combo PCI Ethernet Adapter (8432BT) 
SMC EtherPower 10/100 Fast Ethernet EISA Adapter (9232DST) 


| 
[e) ° ° 
* * 








SMC EtherPower 10/100 Fast Ethernet PCI Adapter (9332DST) No 
Thomas-Conrad Ethernet PCI (TC5048-T2) No* 
Thomas-Conrad Tropic 16/4 Token-Ring Adapter/AT (TC4043) Yes 


° 


Xircom External Token-Ring Adapter (ET16BU) [client only] 


Zz 
ro) 


Xircom Pocket Token Ring Adapter III (PT3-16CTP) [client only] 





Xircom Pocket Ethernet Adapter III (PE3-10BT) [client only] 





Xircom Pocket Ethernet Adapter II] (PE3-10BC) [client only] 





| | 
° ° [e) 


Xircom Pocket Ethernet Adapter III (PE3-10BX) [client only] 


216 Inside DSS for OS/2 Warp 





Appendix D. Sample Response Files 


This appendix lists a subset of the response files contained in the 
\CID\SAMPLES directory on the Directory and Security Server for OS/2 Warp 
CD-ROM. The following response files are included: 


Warp Client to DSS Slim Client 
Warp Client to DSS Full Client 


OS/2 LAN Server Entry Backup Domain Controller to DSS Backup 
Domain Controller 


OS/2 LAN Server Entry Additional Server to DSS Additional Server 


Also included is a sample response file describing a three-machine core 
installation. It is heavily commented for your understanding. Thanks to 
Damian Tambirasa and Juan Nuncio for allowing us to include it here. 


For additional information about response files and keywords, refer to the 
DSS Up and Running Guide, Appendix A. 





D.1 Warp Client to Slim DSS Client 


This Response file allows a Warp client to be upgraded to the DSS Slim 
client (see 2.2.7.3, “DSS Slim Client” on page 48 for more information). The 
following parameters were used in example 1: 


Client computer name =MYMACHINE 

Client TCP/IP hostname=machine.example.com 

Client IP address=111.11.11.11 

Cell name=example_cell 

Master Security server TCP/IP hostname=security.example.com 
Initial Directory server TCP/IP hostname=directory.example.com 


Protocol used:TCP/IP 
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# Slim DSS Client 
# Install / Config (Full) 
# file name: cid\samples\dsricf.rsp 


DSSTARGET = D: 
DCETARGET = E: 


INSTALLREQUESTER = INSTALL 
INSTALLMESSENGER = INSTALL 
INSTALLMSGPOPUP) = =_: INSTALL 
INSTALLCLIPBOARD = INSTALL 
INSTALLDSSGUI = INSTALL 


updateibmlan = Networks< 
netl = NETBEUI$, *, *, 60, 120, 12 


> 


updateibmlan = Requester< 
computername = MYMACHINE 


> 
cell_name = example_cell 


master_security_server=( 
tcpip_name = security.example.com 


) 
cds_server=( 
tcpip_name = directory.example.com 


) 


Figure 54 (Part 1 of 2). DSS Slim Client Response File 
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host=( 
host_id=( 


tcpip_name=machine.example.com 
tcpip_addr=111.11.11.11 
netbios_host=MACHINE 


) 


protocols=tcpip 
component s= ( 
slim_client=( 
config_state=configured 


) 
) 
) 


Figure 54 (Part 2 of 2). DSS Slim Client Response File 





D.2 Warp Client to DSS Full Client 


This Response file allows a Warp client to be upgraded to the DSS Full 
client (see 2.2.7.2, “Full Client” on page 47 for more information). The 
following parameters were used in example 2: 


Cell Administrator ID=USERID 

Client TCP/IP hostname=machine.example.com 

Client IP address=111.11.11.11 

Cell name=example_cell 

Master Security server TCP/IP hostname=security.example.com 
Initial Directory server TCP/IP hostname=directory.example.com 


Protocol used:TCP/IP 
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# Full DSS Client 
# Install / Config (Full) 
# file name: cid\samples\dsficf.rsp 


#eSSssSSaSsaSsasssssassssssaSSaSsaSsae= 

DSSTARGET = D: 

DCETARGET = E: 

INSTALLREQUESTER = INSTALL 
INSTALLMESSENGER = INSTALL 
INSTALLMSGPOPUP = INSTALL 
INSTALLCLIPBOARD = INSTALL 
INSTALLDSSGUI = INSTALL 


updateibmlan = Networks< 
netl = NETBEUI$, *, *, 60, 120, 12 


> 


updateibmlan = Requester< 
computername = MYMACHINE 


> 


cell_name = example_cell 
cell_administrator = USERID 


master_security_server=( 
tcpip_name = security.example.com 


cds_server=( 
tcpip_name = directory.example.com 


) 


Figure 55 (Part 1 of 2). DSS Full Client Response File 
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host=( 
host_id=( 


tcpip_name=machine.example.com 
tcpip_addr=111.11.11.11 
netbios_host=MACHINE 


) 


protocols=tcpip 
component s= ( 


client=( 


config_state=configured 


) 
) 
) 


Figure 55 (Part 2 of 2). DSS Full Client Response File 





D.3 Entry Backup Domain Controller to DSS Backup Domain Controller 


This Response file allows an Entry Backup Domain Controller to be 
upgraded to a DSS Backup Domain Controller. The following parameters 
were used: 


OS/2 LAN Server Domain name=DOMNAME 

Client TCP/IP hostname=machine.example.com 

Client IP address=111.11.11.11 

Cell name=example_cell 

Master Security server TCP/IP hostname=security.example.com 
Initial Directory server TCP/IP hostname=directory.example.com 


Protocol used: TCP/IP 


Please note that the INSTALLDSSDC keyword was used twice. You may 
delete the duplicate line. 
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# Backup Domain Controller (Entry) 
# Install / Config (Full) 
# file name: cid\samples\bdcicf.rsp 


#eSSaSSSSSSaesasssssssssssSssSSsSSaSsae= 

DSSTARGET = D: 

DCETARGET = E: 

INSTALLSERVER = INSTALL 
INSTALLDSSDC = INSTALL 
INSTALLMESSENGER = INSTALL 
INSTALLMSGPOPUP = INSTALL 
INSTALLCLIPBOARD = INSTALL 
INSTALLDSSGUI = INSTALL 
INSTALLDSSDC = INSTALL 
INSTALLALERTER = INSTALL 
INSTALLBACKREST = INSTALL 
INSTALLNETRUN = INSTALL 
INSTALLREPLICATOR = INSTALL 
INSTALLTIMESRC = INSTALL 
INSTALLUPS = INSTALL 
INSTALLFFST = INSTALL 
INSTALLGENERICALERTER = INSTALL 
ACLEXP=YES 

DSSEXP=YES 


deleteibmlan = Networks< 
netlb = 
> 


updateibmlan = Networks< 
netl = *, *, *, 60, 120, 12 


> 


Figure 56 (Part 1 of 2). DSS Backup Domain Controller Response File 
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updateibmlan = Requester< 
Domain = DOMNAME 

> 

updateibmlan = Server< 
resourcedomain=resdom 

> 

updateibmlan = Server< 


srvservices = LSSERVER 
> 


ConfigServerType = BackupDC 


cell_name = example_cell 
cell_administrator = USERID 


master_security_server=( 

tcpip_name = security.example.com 
) 
cds_server=( 

tcpip_name = directory.example.com 


host=( 
host_id=( 
tcpip_name=machine.example.com 
tcpip_addr=111.11.11.11 
netbios_host=MACHINE 
) 
protocols=tcpip 
components= ( 
client=( 
config_state=configured 
) 
) 
) 


Figure 56 (Part 2 of 2). DSS Backup Domain Controller Response File 





D.4 OS/2 LAN Server Entry Additional Server to DSS Additional Server 


This Response file allows an OS/2 LAN Server Version 4 or OS/2 Warp 
Server Entry Additional Server to be upgraded to a DSS Additional Server. 
The following parameters were used in example 4: 


* OS/2 LAN Server Domain name=DOMNAME 


* Client TCP/IP hostname=machine.example.com 
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* Client IP address=111.11.11.11 

* Cell name=example_cell 

* Master Security server TCP/IP hostname=security.example.com 
¢ Initial Directory server TCP/IP hostname=directory.example.com 


* Protocol used:TCP/IP 


# Additional File and Print Server (Entry) 
# Install / Config (Full) 
# file name: cid\samples\afpicf.rsp 


DSSTARGET = D: 
DCETARGET = E: 


INSTALLSERVER = INSTALL 
INSTALLMESSENGER = INSTALL 
INSTALLMSGPOPUP = INSTALL 
INSTALLCLIPBOARD = INSTALL 
INSTALLDSSGUI = INSTALL 
INSTALLALERTER = INSTALL 
INSTALLBACKREST = INSTALL 
INSTALLNETRUN = INSTALL 
INSTALLREPLICATOR = INSTALL 
INSTALLTIMESRC = INSTALL 
INSTALLUPS = INSTALL 
INSTALLFFST = INSTALL 
INSTALLGENERICALERTER = INSTALL 
ACLEXP=YES 

DSSEXP=NO 


Figure 57 (Part 1 of 2). Entry Additional Server Response File 
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deleteibmlan = Networks< 
netlb = 

> 

updateibmlan = Networks< 
netl = *, *, *, 60, 120, 12 

> 

updateibmlan = Requester< 
Domain = DOMNAME 

> 

updateibmlan = Server< 
resourcedomain=resdom 
srvservices = LSSERVER 


> 
ConfigServerType = AdditionalServer 
cell_name = example_cell 
cell_administrator = USERID 
master_security_server=( 

tcpip_name = security.example.com 


cds_server=( 
tcpip_name = directory.example.com 
) 
host=( 
host_id=( 
tcpip_name=machine.example.com 
tcpip_addr=111.11.11.11 
netbios_host=MACHINE 
) 
protocols=tcpip 
components= ( 
client=( 
config_state=configured 
) 
) 
) 


Figure 57 (Part 2 of 2). Entry Additional Server Response File 


D.5 Three Machine Core Configuration 


This section describes the Response file entries which are needed to create 
Response files for each of the three machines involved in the three machine 
core split configuration. Portions of the example below would be used for 
each server as documented. The following parameters were used in 
example 5: 
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* Cell name=quickstart 

* Cell Administrator ID=CELLADMIN 

* server name(s) =CELLSRV 

¢ Drive default=C: 

* OS/2 LAN Server Domain name=CELLDOM 
« Protocol used:NetBIOS 


;* The keywords below concern installation of DSS. The first three lines*/ 


;* will be where DSS will be installed. All three lines should point to 
3;* the same hard file. Why three ????? 


FILE =iCs 
AUX1 aCe 
AUX2 aC: 


* The next keywords describe to the software installer what components 

* of DSS you want installed. Comment out the components you don’t want 
* installed. 1’11 remark on what the component is at the same line as 

* the description, but I don’t think the parser likes keywords and a 

* comment on the same line so get rid of it when you use this response 

* 


file. Remember you have to know what goes with what and ask for it. 
COMP = DCECL 3; DCE client 
COMP = DCEGUI 3; The DCE GUI interface 
COMP = DCECDSSV ; CDS Server 
COMP = DCESECSV ; Security Server 
;COMP = DCEDFSCL ; DFS Client 


Figure 58 (Part 1 of 12). Documented Response File Components 
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*/ 
*/ 


*/ 
*/ 
*/ 
*/ 
*/ 
*/ 


COMP 
COMP 
COMP 
COMP 


COMP 
COMP 
COMP 
COMP 
COMP 


COMP 
3 COMP 
COMP 
COMP 
COMP 
COMP 
COMP 


COMP 
COMP 
COMP 
COMP 
COMP 


DSSCL 
DSSGUI 
DSSSRV 
DSSDC 


MESSENGR 
MSGPOPUP 
DDECLIP 
FTADMIN 
ALERTER 


BACKREST 
= MIGRATE 
NETRUN 
REPLICTR 
TIMESRC 
GENALERT 

UPS 


HPFS386 
FAULTOS2 


FFST 
DCEBOOKS 
DSSBOOKS 


we we we we 


we we we we we 


we we we we we we we 


> 


DSS Client 


DSS GUI 
Server 


File and Print Server 


LS 
LS 
LS 
LS 
LS 


LS 
LS 
LS 
LS 
LS 
LS 
LS 


LS 
LS 





LS 


DCE Books 
3; DSS Books 


stuff. 
stuff. 
stuff. 
stuff. 
stuff. 


stuff. 
stuff. 
stuff. 
stuff. 
stuff. 
stuff. 
stuff. 


stuff. 
stuff. 


stuff. 


; Do not change the following parameters: 


CFGUPDATE 
OVERWRITE 
SAVEBACKUP 
DELETEBACKUP 


AUTO 
YES 
NO 
NO 


Figure 58 (Part 2 of 12). Documented Response File Components 
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;* These next keywords describe the configuration parameters. You can */ 
;* split the response files into 2 different ones and invoke the DSS */ 
;* install program twice if you have to do something between the install */ 
3;* and configuration, but this is much easier. */ 
;* All the following are for config. The DSS as below will come up with */ 
;* NETBIOS and the names as in the Demo. Change what you want and point */ 
;* to it with the .cmd file. All this stuff is documented in the DSS Up */ 
;* and Running Guide starting on page 166. I’m not going to redocument */ 
;* the information but I’11 go through some of the stuff. */ 
;* our cell name. */ 


cell_name=quickstart 


max_unix_id=2147483647 


3;* book says name of cell administrator. This is not YOUR name. It */ 
3* really means the userid of the DSS administrator. */ 


cell_administrator=CELLADMIN 


min_group_unix_id=100 
min_organization_unix_id=100 
min_principal_unix_id=100 


;* These next two are only for your resource domain computers. These */ 
;* are the other DSS machines that are NOT the Security Master/Initial */ 
;* CDS machine. These lines tell the other DSS machines who the Security*/ 
;* Master/Initial CDS server is. Leave the lines out if you are doing */ 
;* the Master Security/Initial CDS machine. */ 


master_security_server=( 
netbios_host=CELLSRV 
) 


cds_server=( 
netbios_host=CELLSRV 


) 


Figure 58 (Part 3 of 12). Documented Response File Components 
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;* Now we tell config something about our machine and the protocols we */ 
3;* want. Again, for the DSS demo we used NETBIOS, but this is where you */ 
3* change that to TCP/IP or whatever. */ 


host=( 
dce_hostname=CELLSRV 
lan_profile=lan-profile 
netbios_adapter=0 
protocols=netbios_stream 


3;* We always want a full config. This gets the machine info into the */ 
;* CDS name space. */ 


config _type=full 


;* Your choice here. If you want DCE to come up at reboot time or come */ 
;* up later. */ 


autostart=no 


* We didn’t for this demo, but I like to say yes to sync_clock. Now this*/ 
* js used when DCE is started. That means DCE is already configured. */ 
* You MUST get the machines within 5 minutes of each other when you are */ 
;* doing the initial install/config. OR IT WILL FAIL!!! the %/ 
* jnstall/config. You need to check the TZ environment variable also */ 
* on all the machines because the machines need to be within 5 minutes- */ 
;* this means the date too! */ 


autostart_sync=no 
sync_clock=no 


;* You’ ve got some options here. DSS daemons can come up in their own */ 
;* windows, all of them in one window and it shows up in the window list */ 
3* or, aS in below, all in one window and it doesn’t show up in the */ 
;* window list. */ 


start_mode=detached 


Figure 58 (Part 4 of 12). Documented Response File Components 


Appendix D. Sample Response Files 


229 


;* Below you identify the host name. We used NETBIOS, but you can put */ 


;* in tcpip_name and tcpip_addr if you are using TCP/IP. */ 
host_id=( 

netbios_host=CELLSRV 

) 
;* Now we get to specify what components we want to configure. This is */ 
;* the tricky part. What you ask to get installed and */ 
;* what machine you are configuring will determine how you answer below. */ 
;* We’ 11 keep in mind what we did in the demo and what you can do. */ 


components=( 
3;* We will look at the clients first. Do not change the first two lines.*/ 
3;* This is an initial install so we will not do anything forced or worry */ 
;* about unconfiging the dependents. */ 


Each line is pretty much self-explanatory. The only confusing part is */ 
the config state keyword. This key_word is asking what you want, NOT */ 
what the state is. So if you want to configure a component you type */ 
in ===> configured <===. If you don’t want a component configured you*/ 
type in ===> not_configured <===. */ 


we we we 
+ + F F 


we 


client=( 
config_state=configured 
unconfig_depend=no 
force_unconfig=no 


slim_client=( 
config_state=not_configured 
unconfig_depend=no 
force_unconfig=no 


) 


Figure 58 (Part 5 of 12). Documented Response File Components 
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;* You have to configure the sec_cl (security client) if you are doing */ 

;* sec_svr (security server), sec_rep (security replica), cds_svr (cds */ 

;* server) or cds second (additional cds server). This will be the */ 

;* situation on your first DSS machine (Security Master/Initial CDS). */ 

;* Other machines just need the sec_cl. */ 
sec_cl=( 


config state=configured 
unconfig_depend=no 
force_unconfig=no 
) 

sec_svr=( 
config state=configured 
unconfig_depend=no 
force_unconfig=no 


) 


;* This is for your security replica machines. So on your first machine */ 
;* you DO NOT WANT sec_rep. If you are doing a security replica then you*/ 
;* want the component below configured. *f 


sec_rep=( 
config_state=not_configured 
unconfig_depend=no 
force_unconfig=no 


) 


;* Same thing for the CDS as for the Security components. If you are */ 
;* doing the first machine then you need the cds_svr (cds server) as well*/ 
3* as the cds_cl (cds client.) If you are doing other DSS machines then */ 
3;* just the cds client needs to be configured. */ 


cds_cl=( 
config state=configured 
unconfig_depend=no 
force_unconfig=no 
proxy=no 
) 

cds_svr=( 
config state=configured 
unconfig_depend=no 
force_unconfig=no 


) 


Figure 58 (Part 6 of 12). Documented Response File Components 
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;* You can also do additional cds machines. That is the component below. */ 
;* You do NOT configure cds_second on your first DSS machine, just any */ 
;* other computer you want as an additional cds. i 


3* I didn’t do the stuff below for the DSS demo.. Look at Up and Running*/ 
;* Guide page 176-180 for the stuff below. */ 


cds_second=( 
config_state=not_configured 
unconfig_depend=no 
force_unconfig=no 
) 

gda_svr=( 
config_state=not_configured 
unconfig_depend=no 
force_unconfig=no 


dts_client=( 
config_state=not_configured 
unconfig_depend=no 
force_unconfig=no 


) 


Figure 58 (Part 7 of 12). Documented Response File Components 
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;* I did do a time server (local) for the DSS demo. This means for the */ 
;* other machines I did the dts_client (line just above): */ 


dts_local=( 
config _state=configured 
unconfig_depend=no 
force_unconfig=no 
role=non_courier 


) 

dts_global=( 
config_state=not_configured 
unconfig_depend=no 
force_unconfig=no 
role=non_courier 


sec_audit=( 
config_state=not_configured 
unconfig_depend=no 
force_unconfig=no 
) 

dfs_client=( 
config_state=not_configured 
unconfig_depend=no 
force_unconfig=no 
auto_mount=yes 
drive=+ 
mount_directory=/: 
cache_location=disk 
cache_directory=c:\opt\dcelocal\var\adm\dfs\cache 
cache_size=6400 
chunk_size=64 
) 

ems= ( 
config_state=not_configured 
unconfig_depend=no 
force_unconfig=no 


) 


Figure 58 (Part 8 of 12). Documented Response File Components 
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;* Password sync and password strength were configured. ONLY ONE OF EACH */ 
3;* IN A DSS CELL. Very important. Only one of each or you WILL have */ 
;* problems: */ 


pw_sync_svr=( 

config_state=configured 
unconfig_depend=no 
force_unconfig=no 
enable_sync=yes 
retry_interval=300 
foreign_protect_level=cdmf 
master_protect_level=cdmf 
account= ( 

name=1spwsd 

protect_level=cdmf 

) 
) 

pw_strength_svr=( 

config_state=configured 
unconfig_depend=no 
force_unconfig=no 
server_command=C: \ibmlan\netprog\1spwsd.exe 
account= ( 

name=1spwsd 

protect_level=cdmf 


) 


Figure 58 (Part 9 of 12). Documented Response File Components 
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;* That’s it for the component configuration part. 


DELETEIBMLAN 


Networks< 


net2 
net3 
net4 = 
netlb = 


UPDATEIBMLAN 


Networks< 

netl = NETBEUI$,0,LM10,60,120,12 
> 
DELETEIBMLAN = Requester< 


wrkservices = PEER 
wrknets = NETLB,NET2,NET3,NET4 


UPDATEIBMLAN = Requester< 
Computername = CELLSRV 


Domain = CELLDOM 
useallmem = Migrate 


ADDIBMLAN = Requester< 


wrkservices = MESSENGER,DSSDCE,LSPWSYNC 
wrknets = NET1 


The rest is LS stuff.*/ 


Figure 58 (Part 10 of 12). Documented Response File Components 
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DELETEIBMLAN = Server< 


srvservices = ALERTER,DLRINST,DCDBREPL,GENALERT,NETRUN,REMOTEBOOT ,REPLICATOR,UPS 
srvnets = NETLB,NET2,NET3,NET4 


> 
UPDATEIBMLAN = Server< 


resourcedomain = CELLDOM 
autopath = Migrate 


> 
ADDIBMLAN = Server< 


srvservices = LSSERVER,NETLOGON, TIMESOURCE,DIRSYNC 
srvnets = NET1 


> 


UPDATEIBMLAN = SyncSrv< 


sync_required = yes 


Figure 58 (Part 11 of 12). Documented Response File Components 
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;* You might have to change some lines below depending on your computer. */ 


Config386Cache = WSDetermineSize 
ConfigApp|]DumpPath = Migrate 
ConfigApp|]MaxDumps = Migrate 
ConfigAutoStartFFST = No 
ConfigAutoStartLS = Yes 
ConfigCopyDLR = Copy 
ConfigCopyDOS = Copy 
ConfigCopyLSP = Copy 
ConfigCopyOS2Requester = Copy 
ConfigDisplayMSG = Migrate 
ConfigDosVersion = Migrate 
ConfigDosNumber = 0 

ConfigHeap = WSDetermineSize 
ConfigInitializeDCDB = NO 
ConfigLazyWrite = Delayed 
ConfigMaxCacheAge = 5000 
ConfigMinBufferIdle = 500 
ConfigMsgLogName = Migrate 
ConfigServerType = DomainController 
ConfigSystemDumpPath = Migrate 
ConfigSystemMaxDumps = Migrate 
ConfigTargetDrive = C 
ConfigUpsPort = COM1 
ConfigUseAl1lMem = Migrate 
ConfigWsId = Migrate 
ConfigWsSeriall = Migrate 
ConfigWsSerial2 = Migrate 
ConfigWsTypel = Migrate 
ConfigWStype2 = Migrate 
ConfigParentResDom = root 
ConfigAutoStartPWS = CONFIG 
DSSADMIN = Migrate 
DSSConfigType = FULL 
HPFS386DRIVES = C 


Figure 58 (Part 12 of 12). Documented Response File Components 
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Appendix E. Special Notices 


This publication is intended to help anyone who sells, plans, installs, or 
supports the Directory and Security Server for OS/2 Warp. The information 
in this publication is not intended as the specification of any programming 
interfaces that are provided by the Directory and Security Server for OS/2 
Warp product. See the PUBLICATIONS section of IBM Programming 
Announcement 296-273 for the Directory and Security Server for OS/2 Warp 
for more information about what publications are considered to be product 
documentation. 


References in this publication to IBM products, programs or services do not 
imply that IBM intends to make these available in all countries in which IBM 
operates. Any reference to an IBM product, program, or service is not 
intended to state or imply that only IBM’s product, program, or service may 
be used. Any functionally equivalent program that does not infringe any of 
IBM’s intellectual property rights may be used instead of the IBM product, 
program or service. 


Information in this book was developed in conjunction with use of the 
equipment specified, and is limited in application to those specific hardware 
and software products and levels. 


IBM may have patents or pending patent applications covering subject 
matter in this document. The furnishing of this document does not give you 
any license to these patents. You can send license inquiries, in writing, to 
the IBM Director of Licensing, IBM Corporation, 500 Columbus Avenue, 
Thornwood, NY 10594 USA. 


Licensees of this program who wish to have information about it for the 
purpose of enabling: (i) the exchange of information between independently 
created programs and other programs (including this one) and (ii) the 
mutual use of the information which has been exchanged, should contact 
IBM Corporation, Dept. 600A, Mail Drop 1329, Somers, NY 10589 USA. 


Such information may be available, subject to appropriate terms and 
conditions, including in some cases, payment of a fee. 


The information contained in this document has not been submitted to any 
formal IBM test and is distributed AS IS. The information about non-IBM 
(“vendor”) products in this manual has been supplied by the vendor and IBM 
assumes no responsibility for its accuracy or completeness. The use of this 
information or the implementation of any of these techniques is a customer 
responsibility and depends on the customer’s ability to evaluate and 
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integrate them into the customer’s operational environment. While each 
item may have been reviewed by IBM for accuracy in a specific situation, 
there is no guarantee that the same or similar results will be obtained 
elsewhere. Customers attempting to adapt these techniques to their own 
environments do so at their own risk. 


Any performance data contained in this document was determined in a 
controlled environment, and therefore, the results that may be obtained in 
other operating environments may vary significantly. Users of this 
document should verify the applicable data for their specific environment. 


The following document contains examples of data and reports used in daily 
business operations. To illustrate them as completely as possible, the 
examples contain the names of individuals, companies, brands, and 
products. All of these names are fictitious and any similarity to the names 
and addresses used by an actual business enterprise is entirely 
coincidental. 


Reference to PTF numbers that have not been released through the normal 
distribution process does not imply general availability. The purpose of 
including these reference numbers is to alert IBM customers to specific 
information relative to the implementation of the PTF when it becomes 
available to each customer according to the normal IBM PTF distribution 
process. 


The following terms are trademarks of the International Business Machines 
Corporation in the United States and/or other countries: 


IBM 
The following terms are trademarks of other companies: 
C-bus is a trademark of Corollary, Inc. 


PC Direct is a trademark of Ziff Communications Company and is 
used by IBM Corporation under license. 


UNIX is a registered trademark in the United States and other 
countries licensed exclusively through X/Open Company Limited. 


Microsoft, Windows, and the Windows 95 logo 
are trademarks or registered trademarks of Microsoft Corporation. 


Other trademarks are trademarks of their respective companies. 
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Appendix F. Related Publications 


The publications listed in this section are considered particularly suitable for 


a more detailed discussion of the topics covered in this redbook. 





F.1 International Technical Support Organization Publications 


For information on ordering these ITSO publications see “How to Get ITSO 
Redbooks” on page 243. 


Understanding OSF DCE 1.1 for AlX and OS/2, SG24-4616 
IBM DSS and DCE Cross-Platform Guide, SG24-2543 
DCE Cell Design Considerations, SG24-4746 


OS/390 Security Services and RACF-DCE Interoperation, SG24-4704 
Administering IBM DCE and DFS Version 2.1 for AIX and OS/2 Clients, 


SG24-4714 


Understanding Performance Tuning Theory for IBM OS/2 LAN Server, 


GG24-4430 


Inside OS/2 Warp Server, Volume 1: Understanding the Core 
Components, SG24-4602 


Inside OS/2 Warp Server, Volume 2: System Management, 
Backup/Recovery and Advanced Print Services, SG24-4702 


F.2 Redbooks on CD-ROMs 


Redbooks are also available on CD-ROMs. Order a subscription 


receive updates 2-4 times a year at significant savings. 


CD-ROM Title Subscription 
Number 
System/390 Redbooks Collection SBOF-7201 
Networking and Systems Management Redbooks Collection SBOF-7370 
Transaction Processing and Data Management Redbook SBOF-7240 
AS/400 Redbooks Collection SBOF-7270 
RS/6000 Redbooks Collection (HTML, BkMgr) SBOF-7230 
RS/6000 Redbooks Collection (PostScript) SBOF-7205 
Application Development Redbooks Collection SBOF-7290 
Personal Systems Redbooks Collection SBOF-7250 


and 


Collection Kit 
Number 
SK2T-2177 
SK2T-6022 
SK2T-8038 
SK2T-2849 
SK2T-8040 
SK2T-8041 
SK2T-8037 
SK2T-8042 





F.3 Other Sources of Information 


These publications are also relevant as further information sources: 


How to Manage PC Server Environments, SG24-4879 
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OS/2 Warp Server, Windows NT, and Netware: A Network Operating 
System Study, SG24-4786 


These Web sites are also relevant as further information sources: 


e 


Online Documentation for DCE Version 1.1: 

http://www. transarc.com/afs/transarc.com/publ ic/www/Public/Documentation/dce/1.1/ 
Network interface card support for OS/2: 

http://www. austin. ibm.com/pspinfo/nic.htm 

DCE cell performance white paper: 
http://developer.austin.ibm.com/sdp/library/aixpert/nov95/aixpert_nov95_ dce.html 


”“Directory and Security Server Configuration and Tuning” article from 
Personal Systems magazine: 


http://pscc.dfw. ibm. com/psmag/jan97/tech/dira.htm 
DSS Home Page: 

http: //www.software. ibm.com/is/sw-servers/directory/ 
DSS Logon Capacity Estimator information: 


http: //www.software. ibm.com/is/sw-servers/directory/dssbks05.htm] 
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How to Get ITSO Redbooks 


This section explains how both customers and IBM employees can find out about ITSO redbooks, 
CD-ROMs, workshops, and residencies. A form for ordering books and CD-ROMs is also provided. 


This information was current at the time of publication, but is continually subject to change. The 
latest information may be found at http://www.redbooks.ibm.com. 





How IBM Employees Can Get ITSO Redbooks 


Employees may request ITSO deliverables (redbooks, BookManager BOOKs, and CD-ROMs) and 
information about redbooks, workshops, and residencies in the following ways: 


PUBORDER — to order hardcopies in United States 

GOPHER link to the Internet - type GOPHER.WTSCPOK.ITSO.IBM.COM 
Tools disks 

To get LIST3820s of redbooks, type one of the following commands: 


TOOLS SENDTO EHONE4 TOOLS2 REDPRINT GET SG24xxxx PACKAGE 
TOOLS SENDTO CANVM2 TOOLS REDPRINT GET SG24xxxx PACKAGE (Canadian users only) 


To get BookManager BOOKs of redbooks, type the following command: 
TOOLCAT REDBOOKS 
To get lists of redbooks, type one of the following commands: 


TOOLS SENDTO USDIST MKTTOOLS MKTTOOLS GET ITSOCAT TXT 
TOOLS SENDTO USDIST MKTTOOLS MKTTOOLS GET LISTSERV PACKAGE 


To register for information on workshops, residencies, and redbooks, type the following command: 
TOOLS SENDTO WTSCPOK TOOLS ZDISK GET ITSOREGI 1996 

For a list of product area specialists in the ITSO: type the following command: 
TOOLS SENDTO WTSCPOK TOOLS ZDISK GET ORGCARD PACKAGE 

Redbooks Web Site on the World Wide Web 

http://w3.itso.ibm.com/redbooks 

IBM Direct Publications Catalog on the World Wide Web 

http://www.elink.ibmlink.ibm.com/pb1/pbl 

IBM employees may obtain LIST3820s of redbooks from this page. 

REDBOOKS category on INEWS 

Online — send orders to: USIB6FPL at IBMMAIL or DKIBMBSH at IBMMAIL 

Internet Listserver 


With an Internet e-mail address, anyone can subscribe to an IBM Announcement Listserver. To 
initiate the service, send an e-mail note to announce@webster.ibmlink.ibm.com with the keyword 
subscribe in the body of the note (leave the subject line blank). A category form and detailed 
instructions will be sent to you. 
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How Customers Can Get ITSO Redbooks 


Customers may request ITSO deliverables (redbooks, BookManager BOOKs, and CD-ROMs) and 
information about redbooks, workshops, and residencies in the following ways: 


¢ Online Orders — send orders to: 


IBMMAIL Internet 
In United States: usib6fpl at ibmmail usib6fpl@ibmmail.com 
In Canada: caibmbkz at ibmmail Imannix@vnet.iobm.com 
Outside North America: dkibmbsh at ibmmail bookshop@dk.ibm.com 
* Telephone orders 
United States (toll free) 1-800-879-2755 
Canada (toll free) 1-800-IBM-4YOU 


Outside North America long distance charges apply) 


( 
(+45) 4810-1320 - Danish (+45) 4810-1020 - German 
(+45) 4810-1420 - Dutch (+45) 4810-1620 - Italian 
(+45) 4810-1540 - English (+45) 4810-1270 - Norwegian 
(+45) 4810-1670 - Finnish (+45) 4810-1120 - Spanish 
(+45) 4810-1220 - French (+45) 4810-1170 - Swedish 


- Mail Orders — send orders to: 


IBM Publications IBM Publications IBM Direct Services 
Publications Customer Support 144-4th Avenue, S.W. Sortemosevej 21 
P.O. Box 29570 Calgary, Alberta T2P 3N5 DK-3450 Allerod 
Raleigh, NC 27626-0570 Canada Denmark 

USA 


* Fax — send orders to: 


United States (toll free) 1-800-445-9269 
Canada 1-403-267-4455 
Outside North America (+45) 48 14 2207 (long distance charge) 


+ 1-800-IBM-4FAX (United States) or (+1)001-408-256-5422 (Outside USA) — ask for: 


Index # 4421 Abstracts of new redbooks 
Index # 4422 IBM redbooks 
Index # 4420 Redbooks for last six months 


* Direct Services - send note to softwareshop@vnet.ibm.com 
* On the World Wide Web 


Redbooks Web Site http://www.redbooks.ibm.com 
IBM Direct Publications Catalog http://www.elink.ibmlink.ibm.com/pbl/pbl 


- Internet Listserver 


With an Internet e-mail address, anyone can subscribe to an IBM Announcement Listserver. To 
initiate the service, send an e-mail note to announce@webster.ibmlink.ibm.com with the keyword 
subscribe in the body of the note (leave the subject line blank). 
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IBM Redbook Order Form 


Please send me the following: 


























Title Order Number Quantity 
First name Last name 

Company 

Address 

City Postal code Country 

Telephone number Telefax number VAT number 

e Invoice to customer number 

e Credit card number 

Credit card expiration date Card issued to Signature 


We accept American Express, Diners, Eurocard, Master Card, and Visa. Payment by credit card not 
available in all countries. Signature mandatory for credit card payment. 


How to Get ITSO Redbooks 245 


246 inside DSS for OS/2 Warp 





List of Abbreviations 


ACL Access Control List 

ACP Access Control Profile 

APAR Authorized Program 
Analysis Report 

API Application Program 
Interface 

AS Authentication Service 

CDMF Commercial Data 
Masking Facility 

CDS Cell Directory Service 

CID Configuration 
Installation Distribution 

CTS Courier Time Server 

DC Domain Controller 

DCDB Domain Control 
Database 

DCE Distributed Computing 
Environment 

DES Data Encryption 
Services 

DFS Distributed File System 

DHCP Dynamic Host 
Configuration Protocol 

DIRSYNC Directory 
Synchronization 

DNS Domain Name Services 

DTS Distributed Time 
Service 

EOL End of Line 

EOR End of Record 

EPAC Extended Privilege 
Attribute Certificate 

ERA Extended Registry 
Attribute 

FAT File Allocation Table 

GDA Global Directory Agent 
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GDS 
GMT 
GSSAPI 


GTS 
GUI 
HQ 

IBM 


IDL 


ITSO 


LAN 
LS 
LTS 
MPTS 


NFS 
NIC 

NTP 
OSF 


Os! 


PAC 


PS 
PTGT 


RACF 


RFC 
RGYSYNC 


Global Directory Service 
Greenwich Mean Time 


Generic Security 
System API 


Global Time Service 
Graphical User Interface 
Headquarters 


International Business 
Machines Corporation 


Interface Definition 
Language 


International Technical 
Support Organization 


Local Area Network 
LAN Server 
Local Time Server 


Multiprotocol Transport 
Services 


Network File System 
Network Interface Card 
Network Time Protocol 


Open Software 
Foundation 


Open Systems 
Interconnection 


Privilege Attribute 
Certificate 


Privilege Service 


Privilege Ticket Granting 
Ticket 


Resource Access 
Control Facility 


Request for Comment 


Registry 
Synchronization 
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RIPL 


RPC 
SMB 
TGT 
TPI 
TZ 


248 


Remote Initial Program 
Load 


Remote Procedure Call 
Server Message Block 
Ticket Granting Ticket 

Time Provider Interface 


Time Zone 
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UAS 


UBF 
UTC 


UUID 


WAN 


User Account 
Subsystem (NET.ACC) 


Use-based Feature 


Universal Time 
Coordinated 


Universal Unique 
Identifier 


Wide Area Network 
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Access Controls 
checking sequence for DSS_ 23 
comparing LAN Server and DSS_ 116 
entry types 22, 139 
impact on administration 115 
inDSS 19 
in OS/2 LAN Server 12 


initial container ACLs 21, 139 
initial object ACLS 21, 139 
managing 139 
object ACLs 21, 139 
restrictions in DSS 55 
sparse 12 
types 21 

accounts 


associating to resource domain 135 
cell administrator 114 
creating 121 
creating with NET USER 127 
default resource domain 124 
foreign and guest 117 
icon Context menu options 126 
LAN Server GUEST 117 
mobile user considerations 142 
name restrictions 122 
password restrictions 123 
starting when Master servers are down 
ticket expiration 126 
using RESDOM_ 138 

acct-admin group 114 
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usage and syntax 110 

ACLINIT utility 141 

acronyms 247 
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associating users 135 
backing up Security Server 152 
cds server 149 
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Administration (continued) 
changing server IP address 157 
creating accounts 121 
daylight savings time changes 156 
default groups 114 
DIRSYNC 145 
hints using the GUI 113 
impact of ACLs 115 
managing Access Controls 139 
merging resource domains 143 
mobile user considerations 142 
NET ADMIN command not needed 127 
preferred security replica 152 
recreating desktop folder 113 
restructuring resource domains 142 
RGYSYNC 145 
troubleshooting 145 
typical tasks 114 
using GUI filters 126 
AIX cell considerations 167 
Amalgmamated Widget example 58 
APPLY command 139 
audit-admin group 114 
Authentication 179 
Authentication Service 180 
preauthentication 181 
Authorization 19, 20, 179 
impact of ACLs 117 


benefits 3 
bibliography 241 


C 
CDMF_ 169 
cds-admin group 114 
cdsadv daemon 47 
cdsclerk daemon 47 
Cell 

definition 7 


design example 66, 72 
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clearinghouse 149, 177 
client 
changing IP address 157 
DCE clients 167 
establishing preferred security replica 152 
CLNDESK utility 113 
core servers 28, 60 
Courier Time Servers 191 
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daemons 47 
DCE 
definition 173 
login flow 182 
dced daemon 47 
DCESTART command 165 
DCESTOP command 165 
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desktop folder 148 
Directory Services 
Cell Directory Service 176 
components 176 
Global Directory Agent 179 
restrictions for DSS_ 179 
Global Directory Service 178 
DIRSYNC service 14, 32, 88 
definition 144 
Distributed File Service 191 
Dolly’s Large Bank example 63 
Domain Control Database 9 
Domain Controller 
migration 30 
migration changes 14 
migration considerations 15 
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Domain Name Services (DNS) 178 
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DSS description 2 
DSS desktop folder contents 111 
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conflict resolution 108 
usage and syntax 106 
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dts-admin group 114 
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operator (user) capabilities 115 
OS/2 LAN Server 

account types 13 

ACL Model 12 

aliases 9 

architecture 8 

authorization steps 13 

importing information to DSS 105 

logon flow 10 

migration examples 58, 63 
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RESDOMDL utility 143 
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legacy client considerations 141 
managing 133 
merging with RESDOMMG utility 143 
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sizing example 60, 66 
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AIX servers 172 
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